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:chak@cse.unsw.edu.au] Sent: Fri 31.05.2002 03:27 To: Don Syme Cc: tweed@cs.bris.ac.uk; paul.hudak@yale.edu; haskell@haskell.org Subject: RE: [Fwd: F#] "Don Syme" <dsyme@microsoft.com> 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''
"Don Syme" <dsyme@microsoft.com> writes:
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.
am I wrong to think that would .NET had const'ness a la C++, purity annotations wouldn't be needed? hum, not really. const methods can still modify global state (but not object state)... but at least no need to annotate non-const methods :) off topic: On the subject of const'ness, I've been messing around with it. I've been quite surprised to discover that Java&C# do not have C++'s const (Java has "final" on parameters, but it is dumb) About this: http://merd.net/inoutness.html (beware, half of it is still investigations)
"Don Syme" <dsyme@microsoft.com> wrote,
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.
That's certainly not a .NET-specific issue and it sounds a bit like the arguments against statically-typed languages while everybody else thought that without dynamic typing languages are too restricted.
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.
As I said, this is hardly .NET-specific and we have had no problems with huge libraries, such as GTK+ and HOpenGL. Manuel
participants (3)
-
Don Syme -
Manuel M. T. Chakravarty -
Pixel