6 ms·

Compare this with Liskell (Haskell semantics with Lisp syntax): http://www.liskell.org/ http://www.liskell.org/ With both Hasp and Liskell, one writes code tha

Compare this with Liskell (Haskell semantics with Lisp syntax): http://www.liskell.org/ 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 15y ago
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.
- cabalamat 15y ago
  > I know no one who isn't a PL grad student (guilty) has ever even heard of ML I am not a PL grad student. I have heard of ML. These days I imagine many programmers have heard of ML and Haskell.
  - evincarofautumn 15y ago
    Neither am I, though I confess to hanging out with a couple of them, arguing about language design. We used to argue about religion, but programming languages are more objective and just as contentious.
  - moonchrome 15y ago
    >I have heard of ML. 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.
- TheBoff 15y ago
  "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.
  - lubutu 15y ago
    Especially since they aren't. GHC Haskell, for example, is essentially syntactic sugar for System FC, not λ-calculus.
    - DanWaterworth 15y ago
      And system FC is... a polymorphically typed λ-calculus.
      - TheBoff 15y ago
        Possibly we just a have a different idea of what a lambda calculus is: I was thinking of Church's untyped lambda calculus, which is a much weirder beast than System FC.
        DanWaterworth 15y ago
        Even if you restrict lambda calculus to mean untyped lambda calculus, it's common practice to discard the types once type-checking has completed and continue the compilation without them.
      - deleted 15y ago
        [deleted]
  - 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).
- postfuturist 15y ago
  Is Typed Racket not Lisp? Most Lisps support lazy eval through macros and lambda.
  - mahmud 15y ago
    He also calls Lisp "unsafe", and "LISP". Not good signs.
    - Locke1689 15y ago
      I was imitating the original poster by extrapolating large claims from small differences. I work on Racket. What I really meant is that side effects are not predominantly corralled using monads, but this is not a technical discussion.
      - mahmud 15y ago
        Alright, cheers! :-)
  - Locke1689 15y ago
    I don't know, is it? Are there any specific features that we can point to and say -- "that's a Lisp" and "That's not a Lisp." Or is categorization instead primarily dependent on pedigree? If so, why do we care? What usefulness is this distinction aside from pedagogical purposes?
ScottBurson 15y ago
The author offers his own comparison with Liskell: http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html#comparisons http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html...
kruhft 15y ago
Liskell is pretty much dead in the water. The site is still up but the code (in darcs repositories) is no longer accessible. Searching for another place to find the Liskell code lead me to this project.

Locke1689 15y ago

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.

cabalamat 15y ago
> I know no one who isn't a PL grad student (guilty) has ever even heard of ML I am not a PL grad student. I have heard of ML. These days I imagine many programmers have heard of ML and Haskell.
- evincarofautumn 15y ago
  Neither am I, though I confess to hanging out with a couple of them, arguing about language design. We used to argue about religion, but programming languages are more objective and just as contentious.
- moonchrome 15y ago
  >I have heard of ML. 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.
TheBoff 15y ago
"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.
- lubutu 15y ago
  Especially since they aren't. GHC Haskell, for example, is essentially syntactic sugar for System FC, not λ-calculus.
  - DanWaterworth 15y ago
    And system FC is... a polymorphically typed λ-calculus.
    - TheBoff 15y ago
      Possibly we just a have a different idea of what a lambda calculus is: I was thinking of Church's untyped lambda calculus, which is a much weirder beast than System FC.
      - DanWaterworth 15y ago
        Even if you restrict lambda calculus to mean untyped lambda calculus, it's common practice to discard the types once type-checking has completed and continue the compilation without them.
    - deleted 15y ago
      [deleted]
- 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).
postfuturist 15y ago
Is Typed Racket not Lisp? Most Lisps support lazy eval through macros and lambda.
- mahmud 15y ago
  He also calls Lisp "unsafe", and "LISP". Not good signs.
  - Locke1689 15y ago
    I was imitating the original poster by extrapolating large claims from small differences. I work on Racket. What I really meant is that side effects are not predominantly corralled using monads, but this is not a technical discussion.
    - mahmud 15y ago
      Alright, cheers! :-)
- Locke1689 15y ago
  I don't know, is it? Are there any specific features that we can point to and say -- "that's a Lisp" and "That's not a Lisp." Or is categorization instead primarily dependent on pedigree? If so, why do we care? What usefulness is this distinction aside from pedagogical purposes?

ScottBurson 15y ago

The author offers his own comparison with Liskell: http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html#comparisons http://www-student.cs.york.ac.uk/~anc505/code/hasp/hasp.html...

kruhft 15y ago

Liskell is pretty much dead in the water. The site is still up but the code (in darcs repositories) is no longer accessible. Searching for another place to find the Liskell code lead me to this project.