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#

> > 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.

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.


> unclear whether it's actually possible to write a *compiler* for a
> language which supports self-modifying code...

that self-modifying thing old Lispers are all-to-proud of selling come from
their failed attempts at AI in the 70's.  When it was clear it was going
nowhere, they turned to selling the whole Lisp stack as a cutting edge IDE
similar to the Smalltalk ones.  Both were beaten by Microsoft's one for Basic:
Visual Studio.  worse is better, ftw

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.

there are quite a few notable optimizing compilers for both Common Lisp and
Scheme.  They go as far in performance as possible as expected from bounds
checking and such permit, but usually allows for unsafe flags and type
annotations if one is really willing.


> 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.


type inference no doubt is a real dog...

>
> 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.  The JVM
used to have no tail-call optimization primitive, which is a necessity for
functional languages.  The ones I knew used to be pretty limited in that aspect.
 Now there're plenty of functional languages targetting, but I'm not sure the
JVM implements it or they found a trick around it...

Post a reply to this message