There will be a number of major differences between the two implementations.
Ours is implemented on top of T and will initially require users to obtain
a copy of T (which will be distributed with Haskell) while the Glasgow
group is using LML. In the long run, we plan to supply an entire
environment including incremental compilation, a good debugging system,
and other Haskell specific software tools. The environment supplied with
the initial release will be sparse but usable (we hope!).
Yale's implementation will be far superior Glasgow's! :-)
Any help will be appreciated, and I promise to post a summary of what
I will receive in this newsgroup.
Internet cha...@cs.Buffalo.Edu UUCP charmi%cs.buff...@ubvms.bitnet Bitnet
Grapes, not strawberries!
Good news: we are; we have a parallel implementation running on the
GRIP multiprocessor, with absolute wall-clock speedup over the same
programs running on a comparable uniprocessor (never to be taken
for granted!). This has only recently sprung to life, so it will be
a while before we can report proper results.
Bad news: it only runs on GRIP at present, so that rather limits its
distribution. We have access to a Meiko transputer machine, but it
is quite a lot harder to deal with a distributed memory architecture. The
compiler would port rather easily to a shared-memory multiprocessor,
but we don't have access to one at present.
Simon Peyton Jones
This is to confirm John's announcement for the Glasgow compiler
(available RSN). It is not necessary to have LML to be able to use
Haskell, though the compiler will handle both Haskell and LML. The
speed of Haskell executables is comparable to LML (~50K-70K fcs on a
Sun 3/50 for what that's worth).
We will also be working on a debugger and some other goodies. Details
>Yale's implementation will be far superior to Glasgow's! :-)
Not so: I have some fiendish examples to try on the Yale compiler :-) :-)
This Signature Intentionally Left Blank. E-mail: k...@cs.glasgow.ac.uk
The Haskell implementation team: