Hacker News Reader

Comment by ridiculous_fish | Hacker News Reader

But this doesn't require the proliferation of implementations. Each little project doesn't require its own garbage collector, for example.

The paper I linked discusses some of the "practical" areas of Haskell: profiling, debugging, packaging, FFI, compiler errors and optimizations, etc. Surely there's a lot of energy being expended replicating this stuff across the various Lisp implementations?

View on HN

There happens to be wide community consensus around a single Haskell compiler, GHC, at the moment, but that's a contingency and there are some other compilers, interpreters, and stuff like GHCJS. Profiling and debugging support is a feature of GHC (and other implementations), not of the language standard.

Common Lisp has unified packaging and FFI and stuff through various community projects like ASDF and Quicklisp.

If you're talking about Lisp in the general vague sense of "Lisps" then there can't be general interoperability because that umbrella term covers lots of very different languages with no formal common ground.

There aren't that many Lisp implementations, especially those that are considered to be mature and ready for production.

For Common Lisp, the open source ones are SBCL and Clozure CL, and the proprietary ones are Allegro CL and LispWorks.

For Scheme, there are Racket (PLT Scheme), Chicken Scheme, and Guile.

I'm quite certain that the majority of people who use Common Lisp and/or Scheme use one of the aforementioned implementations.

Even GC cannot be a common ground for everything. Take a look at Harlan, a Lisp-like language with a region-based memory management. Unification harms diversity and flexibility.

Reply on news.ycombinator.com