On 18/10/2015 12:01 AM, nemesis wrote:
> all of that certainly explains why there're just a few implementations for the
> language.

Actually, there used to be more. (NHC, YHC, Hugs, Helium, ...) It seems 
that GHC is so good now, that nobody thinks they can beat it. All the 
other implementations have gone quiet. (Also, GHC is the only one funded 
by Microsoft. All the others were hobby projects.)

That and the fact that Haskell is an extremely unpopular language 
anyway. How many implementations of Eiffel are there? Last time I 
looked, there were 2. (One commercial and very expensive, one open-source.)

> Having fun with significant whitespace?

Actually, that was reasonably easy. I don't think my implementation is 
perfect, but it currently passes all but 2 of the test cases.

> One of the things that really attracts me to Lisp, or rather its clean and
> minimalist variant Scheme, is the regularity of the language and homoiconicity
> thing.  There's very little actual syntax, just parenthesized prefixed function
> application.  There're loads of implementations for every platform. no
> significant whitespace in sight, but that's traded for parentheses LOL. The
> difference is that they actually help rather than get in the way

I would strongly disagree with that last statement. Unless you can find 
some sort of editor which colour-codes all the braces, it's nearly 
impossible to follow the insanely deeply nested brackets. Much like the 
lambda calculus.

I can certainly see why the highly regular syntax would make 
*implementing* the thing laughably easy. That and the fact that it's an 
untyped language. Writing an interpreter ought to be really simple. I'm 
unclear whether it's actually possible to write a *compiler* for a 
language which supports self-modifying code...

Why are there so few implementations of Haskell? I think it's a 
confluence of several things:

1. Language size. The syntax specification runs to 11 pages of A4. (I'm 
looking at it!) I would imagine a *syntax* spec for Lisp is much 
shorter. I don't even want to /know/ how big the spec for C++ is!

2. Significant whitespace. It's not that hard, but it's annoyingly 
fiddly to get right, which probably puts people off.

3. Implicit types. No, you can't just ignore the type system, because 
for some programs the types implicitly alter which code gets called. It 
is legal for a Haskell program to contain no type signatures at all, and 
yet still have compile-time polymorphism. Type-checking for (say) Java 
is probably very much easier. Just check whether each value is a 
subclass of the explicitly-declared type.

4. Laziness. It depends what you're compiling to, but if you compile to 
some machine-level language, it's *really complicated* to implement 
laziness! It 100% *requires* a garbage collection engine, and it's quite 
fiddly to bind you mind around. If you're compiling to the JVM or 
something, some of these problems go away.

5. Pattern matching. It's a fundamental language primitive, and it's 
modestly non-trivial to implement.

6. Why bother? It's too hard to do in an afternoon, so you're not going 
to do it for fun. It's a rare language, so nobody is going to use it. 
Anything you can build will never be as excellent as GHC, a genuinely 
*state of the art* optimising compiler with decades of R&D behind it. So 
what's your point?

Having just said all that, I recall submitting a small Tcl program to 
this very newsgroup about 10 years ago which implements a small subset 
of Haskell. Implementing Haskell isn't hard; implementing *all* of 
Haskell in a standards-compliant way is hard! I suspect the same goes 
for many other languages... (E.g., it doesn't sound too hard to 
implement the common parts of C. But implementing the entire thing, 
"correctly"? That's way harder than most people think!)

Post a reply to this message