With both Hasp and Liskell, one writes code that is indistinguishable from S-expressions. In fact, they are S-expressions. I don't doubt that Haskell has things that Lisp doesn't and that Lispers should learn from, but this is another example of what Paul Graham said, that adding Lisp-style macros to any language will only result in another dialect of Lisp.
Let's count important features of Lisp beyond the fact that it's functional:
- Dynamically typed
- Unsafe
- Eagerly evaluated
- Syntax is s-expr AST
Important features of Hasp/Liskell:
- Statically typed
- Type classes
- Side effects enforced by monads
- Lazy evaluated
- Syntax is s-expr AST
Congratulations, they have one major similarity. If anything Haskell is a dialect of ML, not LISP. I know no one who isn't a PL grad student (guilty) has ever even heard of ML, but it's helpful to look into the history of PL before you start making uninformed statements which basically amount to, "all functional languages are LISP."
P.S.
All functional languages are syntactic suger on λ-calculus.
This is a bit of a pet peeve for me, really. It seems like an unnecessary pithy dismissal of computation theory.
Haskell compilers generally compile in the following way:
text -> tokens -> AST -> lambda calculus variant -> abstract functional machine code -> imperative IR -> machine code
the AST to lambda calculus variant step is a single step. It takes the Haskell representation of the lambda calculus and outputs lambda calculus.
Contrast this with an imperative compilation:
text -> tokens -> AST -> imperative IR -> machine code
The imperative IR may be LLVM IR. LLVM IR is almost a first order functional programming language, it is certainly not machine code for a turing machine. So imperative languages are not syntactic sugar of a turing machine, there is no desugaring step in the pipeline (except maybe when building the AST).
My point was that although there are functional languages that are syntactic sugar over the lambda calculus, I don't know of any imperative languages (and in fact it would not make sense to design an imperative language) that is syntactic sugar over turing machine code.
I should have made my position clearer. I do agree that compiling any non-pure functional language via lambda calculus is a fruitless endeavor.
I am not a PL grad student. I have heard of ML. These days I imagine many programmers have heard of ML and Haskell.
Specifically F# which is based on OCaml which is based on ML. if F# succeeds "int the wild" I'm guessing a lot more developers will hear about ML.
http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html...