> > ... 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... > > 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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell