On 18/10/2015 04:37 PM, nemesis wrote:
> Orchid Win7 v1<voi### [at] devnull>  wrote:
>> 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.)
>
> oh, yes
>
> Microsoft, the eternal monopoly
>
> they also hired the main researchers for the language and it gave fruits as
> insights for C#'s LINQ and a couple of other features and F#

Oh, you noticed?

It used to be possible to say "hey, look at this Java code. Now look at 
the same thing in Haskell. See how it's 500% shorter and easier to 
comprehend?" But now you can more or less do the same thing in C#, for 
the *common cases* that are easy to demonstrate in a 3-line snippet. 
Trust me, there's still plenty that's easier in Haskell than C#. It's 
just not quite so easy to demo now. :-{

I'm just glad they don't meddle with the actual development of GHC. That 
stays freeware and open-source.

> please don't tell me you use notepad, dude
>
> any halfassed code editor ever since the 70's comes with some parentheses
> matching and coloring resources.  Even web editors in javascript.  It allows for
> quickly going up or down the nested structures as well as selecting a whole
> large section with a single move.

Most editors will highlight the brace matching the one you're currently 
pointing at. But if your source code is 85% braces, anything short of 
colour-coding every single brace with a unique colour is pretty unreadable.

> anyway, the whole metalanguage thing in Lisps may be easier to implement because
> of homoiconicity, but is no different than in other languages:  expansion takes
> place /before/ compilation.  There is eval to construct real new code at
> runtime, but as in javascript and a few others, it's shunned as the performance
> hog it is and function composition is preferred.

OK. So eval actually goes slower. I was half expecting the entire 
compiler to be included at run-time. (Mind you, for something as simple 
as Lisp, maybe it's not that hard...)

>> 3. Implicit types.
>
> type inference no doubt is a real dog...

Actually, this is one of those joyful moments when you look at the 
algorithm and go "oh... that sounds really simple!" It's quite elegant, 
really. Don't get me wrong, there's a butt-load of obscure ways it can 
go wrong, which will leave you scratching your head. But the main idea 
is quite beautiful.

Doing this in a language with subtype polymorphism, OTOH, sounds 
nightmarish. Just for giggles, go look up the Eiffel rules for when one 
generic type is or isn't a subtype of another generic type. It's mental! ;-)

>> 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.
>
> which is funny, because I never heard of a haskell compiler for java.

I guess you haven't heard of Frege then.

(It's a language that's 98% like Haskell, but just different enough to 
prevent all your existing Haskell code from working on it.)

Anyway, the compiler translates Frege into Java. Not JVM bytecode, 
actual Java source code. And supports calling native Java as foreign 
functions (much as GHC supports calling C).

> The JVM
> used to have no tail-call optimization primitive, which is a necessity for
> functional languages.

I suspect you can use a trampoline to get around that. I am not an 
expert in such matters.

Oh, and there's the experimental GHCJS, which is a mod of GHC that 
compiles to JavaScript. For realz.

Post a reply to this message