

Hasp: An S-Expression to Haskell Compiler - kruhft
http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html

======
twfarland
Glad to see another attempt at this righteous marriage. The piping approach is
very tasteful.

I tried to get this working with Racket (on osx) but hit too many blocks and
ended up going with Gambit, which works well so far.

------
winestock
Compare this with Liskell (Haskell semantics with Lisp syntax):
<http://www.liskell.org/>

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.

~~~
Locke1689
I'm sorry but this is just ridiculous. Just because it looks like Lisp (i.e.,
the syntax is s-exprs) doesn't make it 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.

~~~
TheBoff
"Syntactic sugar on the lambda calculus" is just silly, really. I wish people
would stop saying this. It's like saying imperative languages are syntactic
sugar on Turing Machines.

This is a bit of a pet peeve for me, really. It seems like an unnecessary
pithy dismissal of computation theory.

~~~
DanWaterworth
I disagree, it's not like saying "imperative languages are syntactic sugar on
Turing Machines" at all.

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).

~~~
lubutu
And what of Lisp, of which most dialects have mutable state? If a Lisp
compiler would convert to genuine λ-calculus it would be as large a step as it
would for C.

~~~
DanWaterworth
If you would re-read my comment, you'll find that I didn't actually say I
agree that all functional languages are syntactically sweetened lambda
calculus, though I certainly said Haskell was.

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.

------
lalolol
Pro Tip : Examples first

