HN Theater @HNTheaterMonth

I enjoyed this Strange Loop talk: https://www.youtube.com/watch?v=lMcRBdSdO_U

For those who want a good overview of the power of Shen, see this Strange Loop talk: https://youtu.be/lMcRBdSdO_U.

  I was thinking about this the other day.  How can I expose my Common Lisp code to Julia.  
  

1. You could take the Clasp path by exposing CL to C++. https://youtu.be/8X69_42Mj-g

  This means taking /  writing a CL in Julia.
  

2. Julia has an AST representation written in femtolisp. So it would be in interesting target for CL or some glue middle language like Shen. http://www.shenlanguage.org/ https://youtu.be/lMcRBdSdO_U

Every time I hear about Shen I think about this talk: https://www.youtube.com/watch?v=lMcRBdSdO_U

Stanza looks very interesting. I'll have to check it out. Thanks!

Shen allows you to turn the type checker on or off:

(tc +)

(tc -)

You can leave your type signatures in the code when you turn them off, and when tc is on you only need a type in the top level of your function.

It has a fully functional Prolog engine built in, and it supports optional lazy evaluation too.

Great talk by Aditya Siram Sept 2014 Strange Loop talk introducing Shen [2]. Shen has been ported to many languages, since it only requires porting the 46 primitive instruction set, called Klambda. Shen has been ported to CL (SBCL), Ruby, JavaScript, Haskell and even Emacs Lisp.

[1] http://shenlanguage.org/ [2] https://www.youtube.com/watch?v=lMcRBdSdO_U

I am learning Shen [1], and this talk [2] shows how you can write Shen on JavaScript, Ruby, front an backend. Shen is a lisp with pattern matching, optional lazy evaluation, optional static type checking, macros of course, and many other cool treats! It can run on top of CL (SBCL), Clojure, JavaScript, Python, and more.

  [1] http://www.shenlanguage.org/
  [2] https://www.youtube.com/watch?v=lMcRBdSdO_U

Looking for a feel for Shen?

A Strange Loop talk by @deech (40minutes): Shen: A Sufficiently Advanced Lisp. https://www.youtube.com/watch?v=lMcRBdSdO_U

An essay: http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

It's insightful and readable and it links to several articles new Shen users would be interested in[0]. It was written before Shen, so it talks about Shen's predecessor, Qi. This article and the Bipolar Lisp Programmer by Mark Tarver (creator of Shen) made me feel not so weird for not "getting" UNIX, and helped me get excited about lisp.

I'm looking to use Shen or another highly cross-platform functional language for my next project. Application logic in Shen with type-checking. web code using some framework.

[0] Wow I'm re-skimming it now: it has Stanislav, James Gosling, buncha Smalltalk, Rob Pike's "Systems Research is Dead" and a lot more. This is actually a good overview of ways to be disillusioned with programming. IMO disillusionment by knowing our historical failures is an antidote to the hype-machine.

⬐ spion

I loved the essay and how it explains the problems with collaboration in Lisp

One thing I'd like to add though: The reason collaboration fails isn't just NIH being easy. The language is so malleable that its hard (sometimes even impossible) to understand other people's code. You have to get into the their mind and adapt to their way of thinking to make any meaningful contributions. For every new developer, you potentially get to learn a completely new and different language that need not have any principles behind it (at least Haskell EDSLs are all guided by the same principles of a few type classes and concepts from category theory).

So, inventing your own stuff is easy, and at the same time understanding other people's stuff is hard.

⬐ dgreensp

It's pretty strange to see a "Lisp" with so much syntax. Lots of infix notation, and even semicolons! Usually Lisps have a very simple reader that reads S-expression and a few other things, but here we have this:

  (define map
    { (A --> B) --> (list A) --> (list B) }
    F [] -> []
    F [ X | XS ] -> [(F X) | (map F XS)])

And this is one of the cases without any semicolons.

Shen also uses the atrocious "curried form" of function types, where the function that adds two numbers has type number->number->number, and the reader must do the mental gymnastics to convert it to (number,number)->number (and good luck when it's more complicated than that).

I wonder if you took a language like Haskell and changed some of the syntax to look Lispy if it could masquerade as a Lisp? I'm not saying that's what's happening, it's just hard to wrap my head around a syntax like this that claims to be Lispy.

⬐ typedweb

http://readwrite.com/2010/11/27/haskell-with-lisp-syntax?_es...!

⬐ deech

You don't have to use any of the syntax if you don't want to. You can write directly in KLambda. Here's how `map` is defined in KLambda:

   (defun map (f l)
     (shen.map-h f l ()))

   (defun shen.map-h (f l accum)
     (cond ((= () l) (reverse accum))
           ((cons? l) (shen.map-h f (tl l) (cons (f (hd l)) accum)))
           (true (shen.f_error shen.map-h))))

⬐ codygman

Put this in my "watch later" queue. I'm very interested in a Lisp whose type system is on par with that of Haskell/Ocaml.

EDIT: Especially since Shen is now BSD licensed.

⬐ 616c

Now, I understand that is BSD licensed, but I am bothered by their proud "we support OSI, but never GPL" attitude. I wonder what happened to the original developer, but does anyone know why he has GPL issues? Yes, I know he is not unique in the industry at large, but I rarely see project download pages with GPL with a red line through it.

http://www.shenlanguage.org/download_form.html

⬐ doublec

The original developers thoughts on GPL have been discussed at length on the Shen mailing list during the BSD licensing donation period. If you look through the archives you'll be able to read their thoughts.

This link may be a start: https://groups.google.com/d/msg/qilang/mVSJIyp-OhM/FjcAOAWUi...

It's unfortunate that the original authors views on licensing takes so much discussion away from Shen itself as it's an interesting language.

⬐ e12e

Thanks for that link. I might not agree with all views presented, but the question about re-licensing as framed there was new to me. I'm very much pro GPL/FSF -- but when leveraging copyright to achive copyleft, it is important to understand the inner workings of copyright, and as this thread highlights the nitty-gritty of "derived work" and the difference between a liberal license to (re)distribute, versus the right to assert copyright, and thereby re-license.

⬐ 616c

So true. I am watching this video and I am very impressed. I am a novice programmer, but from what I read on HN the Shen system hits all cylinders a lot of the more powerful advanced programming paradigms. I am a Shen outsider and there seems to be some much overhead that is not technical when I read about it and it upsets me bc, well, it is a work of art.

I just started studying Java, and found the yet to be certified Java implementation. I am afraid to look at it, lest brains come of my nose.

https://github.com/hraberg/Shen.java

⬐ tluyben2

One of the great advantages of Shen is that it is built on top of a very simple Lisp called KL of which you can (at least basically working) implement an interpreter or compiler in any language in a day. And when you did that, Shen will run on it. That's why there are so many targets and that's why most targets are not mature. I find it a great advantage though; you can make a compiler or runtime embedded in whatever you are doing really fast and then optimise it as you go.

Edit: I would say, if you want to practice on implementing a compiler & runtime (or VM with JIT or LLVM frontend etc) KL is a good place to start. It's so easy (again, to get something working; to optimise etc is obviously just as painful as with any other language implementation) that it is a lot of fun and you learn a lot if you never did it before.

⬐ 616c

Is there any good introductory info on K lambda? I did some quick Googling and Wikipedia searching, I did not find a singular article about this, not general lamdba calculus or something useful to a complete novice like me.

⬐ doublec

I think this from the Shen site describes it: http://www.shenlanguage.org/learn-shen/shendoc.htm#Kl

⬐ tluyben2

Yes, you would use that doc to implement it and then the Shen distribution to test if it works as expected. Unlike Shen, K lambda is quite a simple Lisp implementation, if you know a bit of Lisp it should all look pretty straight forward. It doesn't have any advanced stuff built in; that's all done on top.

⬐ AnimalMuppet

To me, it seems impossible to have both macros and a type system on par with Haskell. Either your macros can no longer do arbitrary textural transformations, or your type system can't reason about macro cases. (Or, I suppose, your type system has to run after the macro transformations, and you could get a type error then just like you could get a syntax error then. But that means your IDE/development environment can't give you any type assistance on macro calls - you have to compile it to find out if it works. (Or, I suppose, your IDE has to run the macro for you and then do the type checking on the resulting post-macro code.))

I am open to being proven wrong, though...

⬐ doublec

ATS had macros: http://ats-lang.sourceforge.net/htdocs-old/TUTORIAL/contents...

I'm not sure if these made it into ATS2 though.

⬐ deech

The second half of the talk (http://www.youtube.com/watch?v=lMcRBdSdO_U&t=17m30s) is about turning a JSON object into a type using macros and meta-programming.

⬐ gmfawcett

MetaOcaml's type-safe staged metaprogramming is not strictly a macro system, but it is morally equivalent: http://okmij.org/ftp/ML/MetaOCaml.html

⬐ sordina

> it seems impossible to have both macros and a type system on par with Haskell

You should check out the work being done on typed template Haskell then.

⬐ andrewchambers

You can have a language which has to be parsed top down, then you can have both complete type info, and arbitrary macros.

⬐ necubi

Scala has macros [0], and as you reasoned the type checker has to run after the macro expansion. That's not a huge downside; to the user it still appears to be a single pipeline (parsing -> macro expansion -> type checking -> compilation).

Haskell also has very powerful metaprogramming facilities, like template haskell [1].

[0] http://scalamacros.org/ [1] https://wiki.haskell.org/Template_Haskell

⬐ alvatar

Once again, types are way overrated. However, Shen is an interesting new Lisp to watch. Needs a more open community, though (like a free book and/or deep documentation).

⬐ lomnakkus

> types are way overrated.

Please show your scientifically rigiorous evidence. Because it appears very few other people have any (either way), so at the very least you could earn a prize if you shared yours! :)

⬐ fchollet

> Because it appears very few other people have any (either way)

If there is no evidence either way, yet every other developer raves about types all the time (the way "connaisseurs" rave about fine wine and expensive scotch despite being unable to objectively tell the difference), doesn't it follow that types are overrated?

⬐ alvatar

That's the point. Here is further discussion of this: http://blog.metaobject.com/2014/06/the-safyness-of-static-ty...

⬐ lomnakkus

Wow. Way to bias the discussion by segueing into to wine and/or whisky! We're not discussing neither wine nor whisky, so... maybe you'll dispense with the hyperbole?

What is your actual point and what is your evidence?

⬐ TJSomething

How about "A Large Scale Study of Programming Languages and Code Quality in Github" by Baishakhi, et al. [1]? That shows a weak correlation between fewer bugs and static typing. There's a stronger correlation between strong typing and fewer bugs.

[1] http://macbeth.cs.ucdavis.edu/lang_study.pdf

⬐ lomnakkus

I am familiar with that study and while I have serious issues with the methodology, I do not think it says what you think it does[1].

[1] If you think it refutes my point, that is.

⬐ 616c

The community is bizarre, I will not lie, but the original developer did release a book quite recently using Shen, although Shen might not be the focus.

http://www.shenlanguage.org/LPC/lpc.html

⬐ tluyben2

There are two books you can buy ; the latter one uses Shen; the first one (The Book of Shen) teaches you Shen. If you know Lisp & Prolog, it should not be hard to pick it up from examples and the source code. The book is worth it, I just wish there was a digital version; I think it would sell a lot more.

⬐ e12e

I've even come to the conclusion that I don't really like dead-tree books any more. I mean, I like them, as a luxury (and I buy used books) -- but since I'll have a reading device/laptop anyway -- any dead tree books are just a waste of resources (trees, print, packaging, transport, storage, transport...).

Now, books have been optimized really, really well -- and actually take up remarkably few resources to make -- but as long as I'll have a device on which to read e-books anyway -- all those resources are wasted.

Just give me a DRM-free epub version, and I'm much more likely to buy your book.

⬐ tluyben2

The community is small but open; agree on the docs.

⬐ Dewie

> Once again, types are way overrated.

You just had to state that, even though it has nothing to do with the rest of your comment? Oh right, I guess that's how flame igniting driveby-comments tend to work - "Once again, startup incubators are way overrated. This forum looks cool. OK, see ya!"

⬐ codygman

> Once again, types are way overrated.

Care to expand on this? I'm curious, what is your opinion and preferred platform/languages?

⬐ tormeh

I'm not the parent, but in noncritical applications an accommodating compiler/interpreter will speed up development. Few advocate such an attitude for critical applications, but whether all compile-time checking should be done in terms of types or not is an open question.

⬐ lomnakkus

Have you never observed this discussion before?

> "I'm not the parent, but in noncritical applications an accommodating compiler/interpreter will speed up development."

What does "speed up development" mean? Does it mean "as fast as you can push it to your users"? Does it mean "as soon as it passed QA"? Does it mean "as soon as we receive no further bug reports on it for at least 6 months"?

⬐ nothrabannosir

Types speed up my development: they obviate a certain kind of unit tests. If you weren't going to write those unit tests without the types, anyway, then it helps because you now catch type mismatches at compile time instead of runtime.

⬐ tormeh

The question is whether types are the most productive area to focus on when developing better compile-time checks. Maybe it would be better to design languages that solve problems by other means.

⬐ tluyben2

With Shen you can use them when you want. So you can create things fast and add types / tests / proofs when you want and when it seems prudent.

⬐ mordocai

Unfortunately I found shen a pain to get into due to it still being mostly a teaching tool. However, if the community builds some nice tooling around it I will definitely give it another look.

⬐ tluyben2

Working on it!

⬐ juliangamble

Shen stands above other languages (apart from Idris and Coq) in the area of dependent types.

⬐ nullc

and apart from ATS.

⬐ doublec

I haven't looked at the ability to have dependent types in Shen - it'd be great to see some examples. A quick search on the mailing list found:

https://groups.google.com/d/msg/qilang/lokvvf0xLJc/20y8ZkzoN... https://groups.google.com/d/msg/qilang/D3tmhQvfnOE/qcsXhRomF...

⬐ 616c

Also interesting and worthy of note is that this project transitioned to BSD recently, and they are doing it as part of a donation drive.

http://www.shenlanguage.org/shenbsd.htm

I am an amateur Lisper, and like others I whined (perhaps irrationally) that their custom non-OSI only one implementation of the language or else license was scaring people off. Not that the BSD license assuages my concerns about community weirdness (hard to describe, but this ia a very personal opinion and you can dismiss it), but I would like to see if the demand will drive open sourcing the code.

Also very cool is that you can find Shen implementations in more than one flavor: Common Lisp, Clojure, Ruby, and more. Definitely check out the site if you have not yet.

⬐ lomnakkus

That was a really weird "episode" in the history of Shen, IMO. I mean, the outcome was good and all, but it was really weird to ask for donations to change the license. I don't think there was any real explanation for that other that "we want money"?

⬐ doublec

I believe it came from a discussion where to draft a new license would require the original developer to pay a lawyer. Someone suggested raising money to pay the developer the money to transition to BSD, a known license, instead of to a lawyer for yet another unknown license.

⬐ lomnakkus

Wow, that's even weirder than I imagined. Regardless, I'm glad it's been freed due to the generosity of some individuals :)

I've only messed around in the REPL. https://www.youtube.com/watch?v=lMcRBdSdO_U gives a fairly practical introduction.

For those wondering about Shen, this Strange Loop talk gives a taste of it https://www.youtube.com/watch?v=lMcRBdSdO_U

⬐ michaelsbradley

I wish Dr. Tarver would make his Book of Shen[1] available via Google Play[2] (or similar). I rarely purchase paper books these days (especially technical books), but am very happy to pay for well-written books and read them on my iPad.

[1] http://www.fast-print.net/bookshop/1506/the-book-of-shen-sec...

[2] https://play.google.com/books/publish/

⬐ lkrubner

This interests me a great deal:

"Qi makes use of the logical notation of sequent calculus to define types. This type notation, under Qi's interpretation, is actually a Turing complete language in its own right. This notation allows Qi to assign extensible type systems to Common Lisp libraries and is thought of as an extremely powerful feature of the language."

http://en.wikipedia.org/wiki/Qi_(programming_language)

What also interests me is that, unlike Java or Scala, adding types is optional, so the types can be layered in. I prefer that style, because when I face a new problem that I have never faced before, I feel that adding type information suggests I know something that I don't actually know. I prefer to add types to a function, once I've come to understand what role a function should play in regards to the problem I'm trying to solve. In that way, the type information also communicates what I have learned about the problem I am trying to solve, versus the areas of my problem that I am still ignorant about, and whose code I can leave untyped while I figure things out.

I am also intrigued by what fogus has written:

"Qi (and its successor Shen) really push the limits of what we might call a Fluchtpunkt Lisp. I suspect it requires a categorization of its own. A few years ago I was looking for a Lisp to dive into and my searching uncovered two extremely interesting options: Clojure and Qi. I eventually went with Clojure, but in the intervening time I’ve managed to spend quality time with Qi and I love what I’ve seen so far. Qi’s confluence of features, including an optional type system (actually, its type system might be more accurately classified as “skinnable”), pattern matching,3 and an embedded logic engine based on Prolog, make it a very compelling choice indeed."

http://blog.fogus.me/2011/05/03/the-german-school-of-lisp-2/

Just recently, here on Hacker News, we had posted an example of a step-by-step explanation of adding types to a working Shen app:

http://www.shenlanguage.org/library/shenpaper.pdf

Someone in the comments on Hacker News highlighted this comment, by the original author of the untyped app:

"No, I didn't think about writing typed version of this program. You know, I'm not "disciplined" kind of person so type discipline is (for now) pretty foreign to me. :) I have the strange feeling that types hampers programmer's creativity."

Mark Taver responded with his own thoughts, which I thought were interesting:

"The underlined sentence is a compact summary of the reluctance that programmers often feel in migrating to statically typed languages – that they are losing something, a degree of freedom that the writer identifies as hampering creativity. Is this true? I will argue, to a degree – yes. A type checker for a functional language is in essence, an inference engine; that is to say, it is the machine embodiment of some formal system of proof. What we know, and have known since Godel's incompleteness proof [9] [11], is that the human ability to recognise truth transcends our ability to capture it formally. In computing terms our ability to recognise something as correct predates and can transcend our attempt to formalise the logic of our program. Type checkers are not smarter than human programmers, they are simply faster and more reliable, and our willingness to be subjugated to them arises from a motivation to ensure our programs work. That said, not all type checkers are equal. The more rudimentary and limited our formal system, the more we may have to compromise on our natural coding impulses. A powerful type system and inference engine can mitigate the constraints placed on what Racketnoob terms our creativity. At the same time a sophisticated system makes more demands of the programmer in terms of understanding."

⬐ moonchrome

>Qi’s confluence of features, including an optional type system (actually, its type system might be more accurately classified as “skinnable”), pattern matching,3 and an embedded logic engine based on Prolog, make it a very compelling choice indeed.

Note that the post is from 2011, in the meantime Clojure got core.typed (optional type checker), core.match (pattern matching), core.logic (logic engine)-

⬐ MTarver

Not really the same. That's rather like saying because I have a chassis and some wheels and an engine piled in the garage, I have a car. They have to be connected together in the right way to make Shen. Shen is available under Clojure and has been for about 2 years.

I'll also add that IMO there is a difference between having these features in a library and having them in the language standard. Common Lisp for instance, has had pattern-matching in various forms, but if you look at the code contributions on comp.lang.lisp these extensions are not often used.

⬐ AnimalMuppet

The problem is, sometimes I know what I'm doing more than the type system does. But sometimes I only think I know more than it does, and actually it knows more than I do. This makes it very difficult to make the typed-vs-untyped choice "correctly". No matter what you choose, sometimes it's the wrong choice.

What's the answer? Maybe gradual type systems? I dream of an IDE where I have a setting for "type rigidity". I'd start with it "off", and just write the code. Then I'd set it to "warn", and see what it complained about. For code to be production, I'd set it to "error".

But for that to work, I'd need some way of telling the compliler "I really know more than you do about that type error you think you're seeing, so trust me on this one". (In effect, this winds up functioning something like C/C++ casts.) The problem comes when it's right and I'm wrong, but I tell it to trust me anyway...

⬐ tel

Taver's comment is particularly illustrative.

His invocation of Gödel's Incompleteness is particularly interesting. Gödel suggests that any fixed formal system must be true for all compatible models and thus, supposing we built the formal system to capture properties of some model we care about, is going to be overly restrictive to capture what we really want.

Fortunately, typed programming languages (taken as the formal proof systems they are) are extensible. Indeed, that's half of what programming is: adding new types (formally or in documentation alone) to help us capture the reasoning for why our program should work.

So, programmers need not fear Gödel so much. Instead, if you embrace the type system then it will help to calculate (up to the current limitations of the logic you've designed and your willingness to wait) the consequences of the logic you've currently designed. And, should the type checker help you to determine that your current system does not capture the behavior you're interested in...

Well, you just introduce a new type and your formal system grows.

⬐ segmondy

I like what Shen has to offer, but it runs on top of other languages hence there's a huge performance hit. There's nothing revolutionary about it, it's just a lisp with pattern matching, lazy evaluation, prolog system, type checking etc.

Having looked at it, it doesn't give much of an edge over say Prolog, I'm yet to see anything that it offer's that Prolog doesn't.

⬐ doall

Shen's powerful T* type system using sequent calculus which is turing complete is revolutionary.

Also, Shen's approach doesn't have a huge performance hit. See benchmarks for Qi implemented in SBCL. http://www.lambdassociates.org/studies/study10.htm

⬐ levosmetalo

"Maybe you want to launch missiles. It's a lisp, not Haskell"

⬐ MTarver

I'll let others judge the originality of Shen.

I would say that the performance of Shen is very much a function of the platform and the person who did the port. The Merlin compiler in Qi II would, as doall points out, outpace the output of a Lisp programmer. I've yet to put all that technology into Shen.

Also, credit to the 2011 Shen committee members who ported Shen to so many platforms, the versatility of being being able to traffic Shen code across languages is what made Aditya's work and talk possible.

⬐ akavel

From what I remember, it has some weird license. I can never remember what exactly is weird about it (or that of Qi, a related project), but on a quick reading now, I think at least this:

"6. [...] In particular it is not permitted to make derived copies of this software which do not conform to the Shen standard or appear under a different title."

(i.e. kinda "no forking" clause, IIUC)

⬐ totalzeroone

I seem to remember that the author only require that the forked Shen satisfies a number of published tests, that is to guarantee that the forked program function like the original Shen in the basis case. A forked program could extended the original one with new capabilities, libraries and ideas. I think that the author of Shen believe that free sofware should not be free as in beer, now he earn some money selling the Shen book. Only my two cents.

⬐ jcrubino

Shen and Qi are written by an academic. More likely than trying to sell the book is the that author is trying to ensure that the core theories that got put into the languages stay in the language with out alterations to the core principles... what exactly those are I never delved into enough for comment but the documents and history point to a very principled author and language being created.

⬐ totalzeroone

After searching for the official specification (a term used formally in the license), the only thing I could find is the web page for the documentation that is called the official shen standard doc, http://www.shenlanguage.org/learn-shen/shendoc.htm, so I suppose the official specification is the content of this page. As I don't have the book of Shen I can't tell if there is further documentation about the "specification of the language".

The author in the license page claims that he is not going to make a fork illegal by changing the standard in such a way as to make the fork retrospectively illegal.

There was one author who made a close source port of Shen in java but then there were big problems. Perhaps he could give a lot of information of what kind of problems are you to encounter when you try to develop a close source product using Shen. The last think I can remember was that he bought the book of Shen for her 16 years old daughter and he was emotionally very interested in Shen but then all went down. [By the way, I apologize for not putting the 's i the third person )). in my other posts.

⬐ totalzeroone

here is the link https://groups.google.com/forum/#!topic/qilang/yL2Eps2cnwY

⬐ MTarver

The issue here was not that the port was closed; but that people helped to build it and gave their time for free on the assumption it was going to be free and readable. My post

https://groups.google.com/forum/?hl=en#!topic/qilang/PJyM6xC...

opened this topic. The rest is history.

I have a clear policy of not contributing my time to closed (for money) software unless I am being paid as a consultant. I do not have any objection as such to closed source software.

Mark

⬐ totalzeroone

Hello Mark. Could you give a link to the "specification of Shen", that is, is there a battery of test that for a fork of Shen certifies that the fork is a conforming with the specification fork?, is the "official standard documentation web page of Shen the text of the specification alluded in the license?

Thanks for you work in Shen.

⬐ MTarver

If you want to see the tests that are currently used; they are in the source code download.

http://www.shenlanguage.org/Download/download.html

See Test Programs/Readme.shen

⬐ MTarver

The license was introduced before Shen was issued in September 2011 (the license came out in June) and for a year or so the only specification was Shendoc (now Shendoc 16). The understanding was that Shen was specified in that document and what was not covered by Shendoc was covered by 'Functional Programming in Qi'. Later a hurriedly introduced text 'The Book of Shen (first edition)' (TBoS) was produced to fill a gap (2012) and this year (January 2014) a more thorough 2nd edition of TBoS (> 400 pages) was published which fixes the language standard very thoroughly. This is currently the canonical standard. You can find a link to that book on the Shen home page.

http://www.fast-print.net/bookshop/1506/the-book-of-shen-sec...

Shen is now very stable and has been for nearly two years. At my suggestion, I posited that it might be better to move the standard to a computable series of tests and this was floated to the 2011 committee that is responsible jointly for all the ports.

http://shenlanguage.org/2011committee.html

Such a change requires the unanimous consent of all the people involved and it seems we have this and a reworded simplified license.

The only obstacle is the work needed to put this test suite together. I've suggested that this suite might be assembled in Github, though for legal reasons the final version must be put in a publicly accessible but tamper-proof place.

Since the type-integrity given out by the system is not better than the strength of the kernel, we take kernel work very seriously. There is already a suite of 126 tests that I run every Shen port through and 2011 members echo these tests. But this informal test suite needs to be amped up to several hundred tests to approach what I consider to be an adequate test suite. It is very boring but important work. So far I have begun assembling all the programs in TBoS into this suite.

These license issues really only affect people who are deeply involved in kernel work and as far as application programmers are concerned, I doubt that it affects them much at all. As far as graphics, concurrency, FFI etc. and add-ons are concerned there are no restrictions. Likewise none on closed source work.

⬐ MTarver

I'll also add that I'll be asking for volunteer contributions on the Shen news group to help assemble this test suite. So people who want to expedite us here can do so.

⬐ hga

The license text itself is sufficiently complicated and multiply redundant it's hard to tell what it's trying to say.

By multiply redundant I mean it tries to say the same thing 3 or more times.

The author/creator is incapable of seeing the problems this presents (let alone the terms of the license he's trying to get across); no matter how interested I might be in the language, this has turned out to be a show stopper.

And, yeah, there's a no forking clause, subjectively judged; he's also has no interest in a test suite, he says there are already enough implementations of the language.