8 ms·

Hello Haskell, Goodbye Lisp (2009)

74 points by psibi 12y ago

ced 12y ago
As a long-time Lisper in AI, Haskell does look intriguing, but I'm more worried about what I would lose. In particular, I'm curious about how DSLs fare in Haskell. I can write first-order logic sentences in Lisp, and they look and behave just like any other Lisp code. I can use evolutionary programming to generate new code on the fly, and send it to the compiler. And I can get really down to the metal if I ever need C-level performance. How do these look in Haskell?
- gamegoblin 12y ago
  Monad do-notation makes domain specific languages pretty easy to implement.
- gizmo686 12y ago
  I've never learned Lisp, but my motivation for learning Haskell (after briefly toying around with it) was to create a DSL. Specifically, I was designing a DSL with the intention of implementing it in python, when I realized that my DSL seemed a lot like a monad in do notation. Implementing it didn't fail to dissapoint in just how easy it was. Having said that, a DSL implemented as a monad does not behave like any other haskell code, in that it is a monad, and only looks like a DSL when used in do notation.
- mietek 12y ago
  Haskell is great for DSLs. Some loose thoughts: - The syntax is clean and extensible. (Function application is `f(x)` in C, `(f x)` in Lisp, and `f x` in Haskell.) - The core language is small, with a suprising amount of functionality implemented as library functions. (Not surprising to a Lisp programmer, though.) - You can define your own infix operators, specify their precedence, and their fixity. (Left, like most mathematical operators, or right, like the exponentiation operator). - Because of Haskell's lazy evaluation, there is no distinction between special and non-special forms, so you don't need macros to build up syntactic sugar for your DSL. (Special forms, such as the C short-circuiting operators `&&` and `||`, only evaluate as much as is necessary, which is what Haskell does across the board.) - But if you really want macros or quasi-quotation, they're part of the language. (Macros are named Template Haskell.) - There is also built-in syntactic sugar which can be re-used for your own instances of common program patterns, such as monadic do-notation, monadic comprehensions, and arrows. There are many examples of Haskell DSLs online. A particularly amusing one is Lennart Augustsson's embedding of BASIC in Haskell, proving beyond all doubt that Haskell is in fact an imperative language, and all this talk about purity is poppycock. [1] [2] Haskell is also great for performance. GHC 7.8.2 is now ready to use, with the Mio high-performance multicore IO manager merged in. [3] The composable nature of Haskell also lends itself to surprisingly powerful optimisations. [4] Now, generating code at runtime and integrating it (interpreted, or even compiled) into the running image is definitely a strength of Lisp, and other under-appreciated artefacts of a future past, such as Smalltalk. I do not know how Haskell fares in this area, but I would like to find out. [1]: http://augustss.blogspot.co.uk/2009/02/regression-they-say-that-as-you-get.html http://augustss.blogspot.co.uk/2009/02/regression-they-say-t... [2]: http://augustss.blogspot.co.uk/2009/02/more-basic-not-that-anybody-should-care.html http://augustss.blogspot.co.uk/2009/02/more-basic-not-that-a... [3]: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... [4]: http://research.microsoft.com/en-us/um/people/simonpj/papers/ndp/haskell-beats-C.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
- chrisdone 12y ago
  As a Lisper who moved to Haskell, you will find Haskell lacking without template-haskell. With TemplateHaskell turned on, you can do the equivalent of quasi-quotes and reader macros: http://chrisdone.com/posts/common-lisp-haskell http://chrisdone.com/posts/common-lisp-haskell But regular, syntax-extending macros aren't possible. E.g. you can't write AIF, there is only quasiquotation. But if you're just worried about DSLs, then that is indeed possible. There's a culture of avoiding template-haskell in favour of using combinators, so you will sometimes have to stomach ugly DSLs with awful operators and silly names. On the other hand lazy functions are like compiler macros, so they compose better than Lisp macros, which generally compose horribly.
orthecreedence 12y ago
Except macros are great for more than just lazy evaluation. For instance, completely altering syntax to make your app make a lot more sense and remove any amount of boilerplate. As far as parallelism, sure Haskell can give that for free. The cost is you have to be pure about everything, which just seems obnoxious to me...especially when you don't necessarily care about parallelism or performance. With lisp, I can use macros to make parallelism just as natural as programming regular lisp. Yes, I have to be explicit about when I'm being parallel and when I'm not. But that doesn't seem like such a big deal to me, and sometimes you want explicit control over your threads. As far as community, I have no doubts the Haskell community is great. But so is the lisp community. There are a lot of bright people who jump at any chance to help out others, and in the past 5 years the CL implementations and community-built libraries have been making leaps and bounds. This isn't to say Haskell isn't a great choice for many, many applications and requirements. But it's not a replacement for lisp, just as lisp isn't a replacement for Haskell. They are two different beasts that are great at different things.
- coolsunglasses 12y ago
  >Except macros are great for more than just lazy evaluation. Haskellers agree, that's why we have Template Haskell. We use it for all sorts of things, like automatically implementing typeclasses (interface'ish) at compile-time. > parallelism, sure Haskell can give that for free Not really. >The cost is you have to be pure about everything Nonsense. Boom, mutable variables: http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions-are-wanted.html http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions... >sometimes you want explicit control over your threads. You can have that in Haskell. You can use green threads or OS threads and optionally pin OS threads to a particular CPU to avoid context-switching. So you can know what you're talking about next time, my recommended guide for Haskell: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525 The concurrency primitives in Haskell are broad and deep, check this book out: http://chimera.labs.oreilly.com/books/1230000000929 http://chimera.labs.oreilly.com/books/1230000000929 --- an ex-Lisper
  - xico 12y ago
    Automatically implementing typeclasses can often be done with just generics http://www.haskell.org/haskellwiki/GHC.Generics http://www.haskell.org/haskellwiki/GHC.Generics
jonathansizz 12y ago
I keep hearing over and over about how great Haskell is, and yet nobody can ever show me anything written in it other than yet another compiler. Haskell is never going to go mainstream. Stop pushing it, because it's getting really tedious.
- marcosscriven 12y ago
  To put a more positive spin on this, I'd be interested if someone could point to a practical, in use, open source project written in Haskell that I could learn from please? All the tutorials and theory make sense, but making the jump to what I can do with other languages still seems a big one.
  - platz 12y ago
    Xmonad http://xmonad.org/ http://xmonad.org/ Git-Annex https://git-annex.branchable.com/ https://git-annex.branchable.com/
  - phaer 12y ago
    Pandoc, which I linked above fits into your question nicely. And because you specifically asked about something to learn from: there are some well made Youtube videos which explain some of the code in pandoc and xmonad: https://www.youtube.com/watch?v=FEFETKhhq8w https://www.youtube.com/watch?v=FEFETKhhq8w
    - marcosscriven 12y ago
      Wow - that video was brilliant, thanks for the recommendation. (Subscribed to Jekor's channel)
  - louthy 12y ago
    I'm a relative newbie when it comes to Haskell; I've found it's best to just get stuck in - pick a project and just go for it. Especially if you're doing real-world stuff, because you'll just get sick to your back teeth of yet another fibonacci tutorial. Once you get stuck-in you'll find yourself on the Hackage docs site a lot, click on the Source link on the top right of every page, you'll find gold in there. A real world thing I did this week (which unfortunately is proprietary so I can't share), was a distributed configuration system for our cluster. It uses the RabbitMQ library[1][2] and Acid-state library[3] to have a per-node config-DB and uses RabbitMQ's guarantees for delivery of updates to the nodes. Messages are serialised using Aeson[4], the Haskell JSON library. I implemented a vector-clock versioning system on top of the Acid-state store to allow the clients to do conflict resolution. It really was a joy to write (around 350 lines of code). The C# client less so, 1000s of lines of boilerplate. I think there's something really impressive about haskell; I tend to have significantly more trust in the code I write because mostly I know the edge cases don't exist. 9 times out of 10 if your code compiles it will work. Although be prepared for the compiler to hate you when you first start. The beatings are worth it though. There's some basic code samples in the links: [1] https://github.com/hreinhardt/amqp https://github.com/hreinhardt/amqp [2] http://videlalvaro.github.io/2010/09/haskell-and-rabbitmq.html http://videlalvaro.github.io/2010/09/haskell-and-rabbitmq.ht... [3] http://acid-state.seize.it http://acid-state.seize.it [4] https://github.com/bos/aeson https://github.com/bos/aeson
ademarre 12y ago
It's interesting to read old introductory posts like this, and then look ahead at future blog posts to see how his opinion evolved. He still loves Haskell: http://newartisans.com/category/haskell/ http://newartisans.com/category/haskell/
- chrisdone 12y ago
  That's John Wiegley. Worked with him at FP Complete for over a year. He loves Haskell more and more every day.
xmonkee 12y ago
I use Clojure for almost everything now, but I must say Haskell looks interesting. My issue is that Clojure is thriving right now, and Haskell has been around longer than I've been and the world sees it as some arcane science. Is it really worth investing my time to learn it if it's really not being used that much?
- Pacabel 12y ago
  I think you might be overestimating the actual usage of Clojure. It's still very much a niche language. Everything I've observed suggests that Scala has a far greater rate of adoption than Clojure, and Scala's usage is still basically irrelevant compared to that of the major entrenched languages. I'd put the adoption of Haskell closer to that of Scala than I would to Clojure.
- rrradical 12y ago
  It seems fair to say that Lisp was also considered arcane for a number of years, although it is now (somewhat) thriving in the form of Clojure. It's a tough question to answer, but I think you're really asking whether it's better to take a chance of being any sort of early adopter, or wait until it's generally accepted. Even though these languages have been around for decades, they are just recently being spliced into the mainstream via lambdas, immutability, etc. So I could easily see Haskell make a comeback.
- lkrubner 12y ago
  Relative to Haskell, Clojure is certainly thriving. Consider: http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scala&l= http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scal... But they both lag Scala.
  - louthy 12y ago
    A sense of perspective? http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scala%2C+c%23%2C+java&l= http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scal...
- pjmlp 12y ago
ColinWright 12y ago
An interesting question[0] was asked by ntoshev[1] in the discussion that ensued when this was submitted a little over five years ago[2]: > Can you give an example of something you can > implement with a Lisp macro, but you can't > implement with Haskell? Much of that discussion is worth reading. The other submissions don't have much discussion. [0] https://news.ycombinator.com/item?id=516208 https://news.ycombinator.com/item?id=516208 [1] https://news.ycombinator.com/user?id=ntoshev https://news.ycombinator.com/user?id=ntoshev [2] https://news.ycombinator.com/item?id=516038 https://news.ycombinator.com/item?id=516038
- cynicalkane 12y ago
  My somewhat neglected library Clearley (https://github.com/mthvedt/clearley https://github.com/mthvedt/clearley) uses a macro system, that lets you write parsers that look a little like pattern-matching functions. To do this, you need to be able to introspect, bind and lookup symbols, and data structures containing symbols, at compile time. You can't do this in Haskell. Template Haskell doesn't help, since IIRC it doesn't support looking up symbols in the same file. With Clojure, If you understand the JVM type system and performance, you can also write high performance DSLs using Clojure macros. https://github.com/clojure/core.logic https://github.com/clojure/core.logic allegedly is a project along these lines, but I haven't looked too much into it. It heavily uses Clojure protocols (which map to Java interfaces) for performance. I had been working on a code generator for Clearley, which sits neglected on my hard drive, but is able to perform just a little slower than unoptimized hand-written parsers. Since in Clojure compile/runtime separation is optional and off by default, you can use Clojure to generate Clojure code, making life a lot easier.
  - Peaker 12y ago
    Template Haskell does support looking up the namespace in the same file.
- logicchains 12y ago
  As Lisp macros are compile time metaprogramming, wouldn't the answer to this depend on whether Template Haskell is considered part of Haskell or just a compiler extension?
pjmlp 12y ago
Why Calculating is Better than Scheming. (1987) http://cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf http://cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf A paper by Phil Wadler about why ML languages are better than Lisp ones for teaching.
greenyoda 12y ago
The comments of this article include a lengthy and interesting reply by Daniel Weinreb (of MIT Lisp Machine and Symbolics fame): http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/#comment-766 http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/#c... The author's reply to Weinreb can be found here: http://newartisans.com/2009/03/the-jvm-and-costs-vs-benefits http://newartisans.com/2009/03/the-jvm-and-costs-vs-benefits

74 points by psibi 12y ago

ced 12y ago

As a long-time Lisper in AI, Haskell does look intriguing, but I'm more worried about what I would lose. In particular, I'm curious about how DSLs fare in Haskell. I can write first-order logic sentences in Lisp, and they look and behave just like any other Lisp code. I can use evolutionary programming to generate new code on the fly, and send it to the compiler. And I can get really down to the metal if I ever need C-level performance. How do these look in Haskell?

gamegoblin 12y ago
Monad do-notation makes domain specific languages pretty easy to implement.
gizmo686 12y ago
I've never learned Lisp, but my motivation for learning Haskell (after briefly toying around with it) was to create a DSL. Specifically, I was designing a DSL with the intention of implementing it in python, when I realized that my DSL seemed a lot like a monad in do notation. Implementing it didn't fail to dissapoint in just how easy it was. Having said that, a DSL implemented as a monad does not behave like any other haskell code, in that it is a monad, and only looks like a DSL when used in do notation.
mietek 12y ago
Haskell is great for DSLs. Some loose thoughts: - The syntax is clean and extensible. (Function application is `f(x)` in C, `(f x)` in Lisp, and `f x` in Haskell.) - The core language is small, with a suprising amount of functionality implemented as library functions. (Not surprising to a Lisp programmer, though.) - You can define your own infix operators, specify their precedence, and their fixity. (Left, like most mathematical operators, or right, like the exponentiation operator). - Because of Haskell's lazy evaluation, there is no distinction between special and non-special forms, so you don't need macros to build up syntactic sugar for your DSL. (Special forms, such as the C short-circuiting operators `&&` and `||`, only evaluate as much as is necessary, which is what Haskell does across the board.) - But if you really want macros or quasi-quotation, they're part of the language. (Macros are named Template Haskell.) - There is also built-in syntactic sugar which can be re-used for your own instances of common program patterns, such as monadic do-notation, monadic comprehensions, and arrows. There are many examples of Haskell DSLs online. A particularly amusing one is Lennart Augustsson's embedding of BASIC in Haskell, proving beyond all doubt that Haskell is in fact an imperative language, and all this talk about purity is poppycock. [1] [2] Haskell is also great for performance. GHC 7.8.2 is now ready to use, with the Mio high-performance multicore IO manager merged in. [3] The composable nature of Haskell also lends itself to surprisingly powerful optimisations. [4] Now, generating code at runtime and integrating it (interpreted, or even compiled) into the running image is definitely a strength of Lisp, and other under-appreciated artefacts of a future past, such as Smalltalk. I do not know how Haskell fares in this area, but I would like to find out. [1]: http://augustss.blogspot.co.uk/2009/02/regression-they-say-that-as-you-get.html http://augustss.blogspot.co.uk/2009/02/regression-they-say-t... [2]: http://augustss.blogspot.co.uk/2009/02/more-basic-not-that-anybody-should-care.html http://augustss.blogspot.co.uk/2009/02/more-basic-not-that-a... [3]: http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask035-voellmy.pdf http://haskell.cs.yale.edu/wp-content/uploads/2013/08/hask03... [4]: http://research.microsoft.com/en-us/um/people/simonpj/papers/ndp/haskell-beats-C.pdf http://research.microsoft.com/en-us/um/people/simonpj/papers...
chrisdone 12y ago
As a Lisper who moved to Haskell, you will find Haskell lacking without template-haskell. With TemplateHaskell turned on, you can do the equivalent of quasi-quotes and reader macros: http://chrisdone.com/posts/common-lisp-haskell http://chrisdone.com/posts/common-lisp-haskell But regular, syntax-extending macros aren't possible. E.g. you can't write AIF, there is only quasiquotation. But if you're just worried about DSLs, then that is indeed possible. There's a culture of avoiding template-haskell in favour of using combinators, so you will sometimes have to stomach ugly DSLs with awful operators and silly names. On the other hand lazy functions are like compiler macros, so they compose better than Lisp macros, which generally compose horribly.

orthecreedence 12y ago

Except macros are great for more than just lazy evaluation. For instance, completely altering syntax to make your app make a lot more sense and remove any amount of boilerplate. As far as parallelism, sure Haskell can give that for free. The cost is you have to be pure about everything, which just seems obnoxious to me...especially when you don't necessarily care about parallelism or performance. With lisp, I can use macros to make parallelism just as natural as programming regular lisp. Yes, I have to be explicit about when I'm being parallel and when I'm not. But that doesn't seem like such a big deal to me, and sometimes you want explicit control over your threads. As far as community, I have no doubts the Haskell community is great. But so is the lisp community. There are a lot of bright people who jump at any chance to help out others, and in the past 5 years the CL implementations and community-built libraries have been making leaps and bounds. This isn't to say Haskell isn't a great choice for many, many applications and requirements. But it's not a replacement for lisp, just as lisp isn't a replacement for Haskell. They are two different beasts that are great at different things.

coolsunglasses 12y ago
>Except macros are great for more than just lazy evaluation. Haskellers agree, that's why we have Template Haskell. We use it for all sorts of things, like automatically implementing typeclasses (interface'ish) at compile-time. > parallelism, sure Haskell can give that for free Not really. >The cost is you have to be pure about everything Nonsense. Boom, mutable variables: http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions-are-wanted.html http://bitemyapp.com/posts/2014-03-25-when-nested-io-actions... >sometimes you want explicit control over your threads. You can have that in Haskell. You can use green threads or OS threads and optionally pin OS threads to a particular CPU to avoid context-switching. So you can know what you're talking about next time, my recommended guide for Haskell: https://gist.github.com/bitemyapp/8739525 https://gist.github.com/bitemyapp/8739525 The concurrency primitives in Haskell are broad and deep, check this book out: http://chimera.labs.oreilly.com/books/1230000000929 http://chimera.labs.oreilly.com/books/1230000000929 --- an ex-Lisper
- xico 12y ago
  Automatically implementing typeclasses can often be done with just generics http://www.haskell.org/haskellwiki/GHC.Generics http://www.haskell.org/haskellwiki/GHC.Generics

jonathansizz 12y ago

I keep hearing over and over about how great Haskell is, and yet nobody can ever show me anything written in it other than yet another compiler. Haskell is never going to go mainstream. Stop pushing it, because it's getting really tedious.

marcosscriven 12y ago
To put a more positive spin on this, I'd be interested if someone could point to a practical, in use, open source project written in Haskell that I could learn from please? All the tutorials and theory make sense, but making the jump to what I can do with other languages still seems a big one.
- platz 12y ago
  Xmonad http://xmonad.org/ http://xmonad.org/ Git-Annex https://git-annex.branchable.com/ https://git-annex.branchable.com/
- phaer 12y ago
  Pandoc, which I linked above fits into your question nicely. And because you specifically asked about something to learn from: there are some well made Youtube videos which explain some of the code in pandoc and xmonad: https://www.youtube.com/watch?v=FEFETKhhq8w https://www.youtube.com/watch?v=FEFETKhhq8w
  - marcosscriven 12y ago
    Wow - that video was brilliant, thanks for the recommendation. (Subscribed to Jekor's channel)
- louthy 12y ago
  I'm a relative newbie when it comes to Haskell; I've found it's best to just get stuck in - pick a project and just go for it. Especially if you're doing real-world stuff, because you'll just get sick to your back teeth of yet another fibonacci tutorial. Once you get stuck-in you'll find yourself on the Hackage docs site a lot, click on the Source link on the top right of every page, you'll find gold in there. A real world thing I did this week (which unfortunately is proprietary so I can't share), was a distributed configuration system for our cluster. It uses the RabbitMQ library[1][2] and Acid-state library[3] to have a per-node config-DB and uses RabbitMQ's guarantees for delivery of updates to the nodes. Messages are serialised using Aeson[4], the Haskell JSON library. I implemented a vector-clock versioning system on top of the Acid-state store to allow the clients to do conflict resolution. It really was a joy to write (around 350 lines of code). The C# client less so, 1000s of lines of boilerplate. I think there's something really impressive about haskell; I tend to have significantly more trust in the code I write because mostly I know the edge cases don't exist. 9 times out of 10 if your code compiles it will work. Although be prepared for the compiler to hate you when you first start. The beatings are worth it though. There's some basic code samples in the links: [1] https://github.com/hreinhardt/amqp https://github.com/hreinhardt/amqp [2] http://videlalvaro.github.io/2010/09/haskell-and-rabbitmq.html http://videlalvaro.github.io/2010/09/haskell-and-rabbitmq.ht... [3] http://acid-state.seize.it http://acid-state.seize.it [4] https://github.com/bos/aeson https://github.com/bos/aeson

ademarre 12y ago

It's interesting to read old introductory posts like this, and then look ahead at future blog posts to see how his opinion evolved. He still loves Haskell: http://newartisans.com/category/haskell/ http://newartisans.com/category/haskell/

chrisdone 12y ago
That's John Wiegley. Worked with him at FP Complete for over a year. He loves Haskell more and more every day.

xmonkee 12y ago

I use Clojure for almost everything now, but I must say Haskell looks interesting. My issue is that Clojure is thriving right now, and Haskell has been around longer than I've been and the world sees it as some arcane science. Is it really worth investing my time to learn it if it's really not being used that much?

Pacabel 12y ago
I think you might be overestimating the actual usage of Clojure. It's still very much a niche language. Everything I've observed suggests that Scala has a far greater rate of adoption than Clojure, and Scala's usage is still basically irrelevant compared to that of the major entrenched languages. I'd put the adoption of Haskell closer to that of Scala than I would to Clojure.
rrradical 12y ago
It seems fair to say that Lisp was also considered arcane for a number of years, although it is now (somewhat) thriving in the form of Clojure. It's a tough question to answer, but I think you're really asking whether it's better to take a chance of being any sort of early adopter, or wait until it's generally accepted. Even though these languages have been around for decades, they are just recently being spliced into the mainstream via lambdas, immutability, etc. So I could easily see Haskell make a comeback.
lkrubner 12y ago
Relative to Haskell, Clojure is certainly thriving. Consider: http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scala&l= http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scal... But they both lag Scala.
- louthy 12y ago
  A sense of perspective? http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scala%2C+c%23%2C+java&l= http://www.indeed.com/jobtrends?q=clojure%2C+haskell%2C+scal...
pjmlp 12y ago

ColinWright 12y ago

An interesting question[0] was asked by ntoshev[1] in the discussion that ensued when this was submitted a little over five years ago[2]: > Can you give an example of something you can > implement with a Lisp macro, but you can't > implement with Haskell? Much of that discussion is worth reading. The other submissions don't have much discussion. [0] https://news.ycombinator.com/item?id=516208 https://news.ycombinator.com/item?id=516208 [1] https://news.ycombinator.com/user?id=ntoshev https://news.ycombinator.com/user?id=ntoshev [2] https://news.ycombinator.com/item?id=516038 https://news.ycombinator.com/item?id=516038

cynicalkane 12y ago
My somewhat neglected library Clearley (https://github.com/mthvedt/clearley https://github.com/mthvedt/clearley) uses a macro system, that lets you write parsers that look a little like pattern-matching functions. To do this, you need to be able to introspect, bind and lookup symbols, and data structures containing symbols, at compile time. You can't do this in Haskell. Template Haskell doesn't help, since IIRC it doesn't support looking up symbols in the same file. With Clojure, If you understand the JVM type system and performance, you can also write high performance DSLs using Clojure macros. https://github.com/clojure/core.logic https://github.com/clojure/core.logic allegedly is a project along these lines, but I haven't looked too much into it. It heavily uses Clojure protocols (which map to Java interfaces) for performance. I had been working on a code generator for Clearley, which sits neglected on my hard drive, but is able to perform just a little slower than unoptimized hand-written parsers. Since in Clojure compile/runtime separation is optional and off by default, you can use Clojure to generate Clojure code, making life a lot easier.
- Peaker 12y ago
  Template Haskell does support looking up the namespace in the same file.
logicchains 12y ago
As Lisp macros are compile time metaprogramming, wouldn't the answer to this depend on whether Template Haskell is considered part of Haskell or just a compiler extension?

pjmlp 12y ago

Why Calculating is Better than Scheming. (1987) http://cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf http://cs.kent.ac.uk/people/staff/dat/miranda/wadler87.pdf A paper by Phil Wadler about why ML languages are better than Lisp ones for teaching.

greenyoda 12y ago

The comments of this article include a lengthy and interesting reply by Daniel Weinreb (of MIT Lisp Machine and Symbolics fame): http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/#comment-766 http://newartisans.com/2009/03/hello-haskell-goodbye-lisp/#c... The author's reply to Weinreb can be found here: http://newartisans.com/2009/03/the-jvm-and-costs-vs-benefits http://newartisans.com/2009/03/the-jvm-and-costs-vs-benefits