5 ms·
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
by DanWaterworth 15y ago
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 15y agoAnd 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 15y agoIf 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.