Comment by codygman
11 years ago
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.
11 years ago
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.
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...
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
ATS had macros: http://ats-lang.sourceforge.net/htdocs-old/TUTORIAL/contents...
I'm not sure if these made it into ATS2 though.
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.
MetaOcaml's type-safe staged metaprogramming is not strictly a macro system, but it is morally equivalent: http://okmij.org/ftp/ML/MetaOCaml.html
> 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.
You can have a language which has to be parsed top down, then you can have both complete type info, and arbitrary macros.
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
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.
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
4 replies →
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.