Hi Manuel,
One point is that in the absence of extensive purity annotations to imperative
libraries you will need to use monads for operations that shouldn't need them. Having
to add the annotations certainly counts as a complication in comparison to what many
other languages have to do on .NET.
As for monads, this is hardly the place to go into an argument about their relative
merits re. all those slightly more widespread approaches to imperative programming.
If you think driving imperative libraries using monads will be so great then a
Haskell.NET would certainly be a perfect place to try out that theory.
Don
-----Original Message-----
From: Manuel M. T. Chakravarty [mailto:[EMAIL PROTECTED]]
Sent: Fri 31.05.2002 03:27
To: Don Syme
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [Fwd: F#]
"Don Syme" <[EMAIL PROTECTED]> wrote,
> 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)
[..]
> 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...
So, you are saying that Haskell's problem with .NET is that
it is not imperative, but at the same time you don't want to
resort to Haskell's imperative sublanguage (the IO monad).
I don't quite understand this.
Personally, I find[1] Haskell to be very pleasant for
imperative programming. In fact, I agree with SPJ, who
wrote[2] (slightly provocatively), Haskell is the world's
finest imperative programming language.
Cheers,
Manuel
[1] After having written piles of low-level imperative code
in Haskell.
[2] In ``Tackling the Awkward Squad''
Ú²G¥–f¢–)à–+- «$zYajÉ –Z+‚m§ÿðÃZ²G¥–Šàþf¢–f§þX¬¶)ߣøZ²G¥
