[Fwd: F#]

[Don Syme]

Sigbjorn has already shown how a non-IL-generating approach is possible.
I think a simple implementation of a Haskell.NET compiling to IL is
feasible, especially if you're willing to do the interop with .NET
components by extending the language as with F# or SML.NET.  It's more
that GHC is a bit of a complex point to start from.

Of course doing a full Haskell implementation from scratch requires an
intimate knowledge of all the features you mention, and is the sort of
thing one only tends to get right on the second or third time you do it.
And getting top-notch performance is obviously always a huge challenge
for Haskell, and you can't play some common implementation tricks when
compiling to IL.  But the only truly serious complications added by .NET
itself are (a) the general problem of Haskell interop with imperative
libraries, requiring you to reach for monads quite often (or to wrap the
libraries yourself) and (b) the well-known problems of combining type
inference, subtyping and overloading, to which you can take a high-tech
approach by using a fancy constraint or inference system, or a low-tech
approach by requiring the programmer to add a few more type annotations
than they may wish.  F# takes the latter approach.

IMHO problem (a) will always be the thing that stops Haskell becoming
very very big.  But then being non-imperative it's also its main selling
point...

Best wishes,
Don



-----Original Message-----
From: D. Tweed [mailto:tweed@compsci.bristol.ac.uk]=20
Sent: 30 May 2002 15:25
To: Don Syme
Cc: Paul Hudak; haskell
Subject: RE: [Fwd: F#]

On Thu, 30 May 2002, Don Syme wrote:

> going to provide.  Given the general complexity of GHC, the longish
> compile times and the reliance of the GHC library implementation on C
> and C libraries in so many places I decided to implement a simpler
> language from scratch.  I like the idea that a .NET compiler should be
> under 10K lines of code if at all possible, as is the case for F#.

Idle curiosity: which aspects of the Haskell language are the ones that
make it complicated -- e.g., long-time stuff like lazy evaluation,
typeclasses & inferrence, etc or newer stuff like functional
dependencies,
etc or something else entirely -- and do they only make it complicated
in
the context of the .NET architecture or in any implementation? (I'm just
interested in that there's little chance of Haskell becoming more
widespread if it's daunting enough to dissuade implementors.)

___cheers,_dave_________________________________________________________
www.cs.bris.ac.uk/~tweed/  |  `It's no good going home to practise
email:tweed@cs.bris.ac.uk  |   a Special Outdoor Song which Has To Be
work tel:(0117) 954-5250   |   Sung In The Snow' -- Winnie the Pooh