[Fwd: F#]

[Don Syme]

> > ... 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) ...
> >
> > 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...
>=20
> Are you saying that Haskell users would reject this?  (to which I
would
> disagree, since that's what we would expect)  Or new users?  (to which
I
> would say that the jury is out)

I was meaning "hundreds of thousands of new users", which is why I put
"very very big".  There's still plenty of scope for Haskell to become
just "very big" without fully solving this problem.

> I would think that the biggest impediment to Haskell.NET would be
> efficiency, in both the generated code (primarily because of lazy
> evaluation) and in compile time (at least with an optimizing compiler
> such as GHC).

These are problems, though not unique to a Haskell.NET.  You are right
that the code performance of Hasekll.NET will not typically be as good
as say GHC and this may require more optimizations that take
considerable time.  But I think a clean re-implementation of a
judiciously chosen subset of the GHC optimizations with a focus on
getting good compilation speeds (i.e. the same agenda that the Caml team
have followed) would see you over this hurdle.  You'd be able to get the
performance needed to attract new programmers, though of course other
Haskell compiler writers may still claim the overall performance crown.


Best wishes,
Don