RE: [Fwd: F#]
Don Syme [EMAIL PROTECTED] 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 ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
At 2002-05-31 12:48, Don Syme 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. But these cases are surely quite rare? In my experience, if it really is pure, chances are Haskell can do it by itself and you don't need a function in the library to do it. Perhaps there are exceptions for maths libraries. It seems to me the simplest thing for foreign libraries is to make all calls monadic. Certainly I do this in JVM-Bridge, all raw FFI calls are in the IO monad and I don't use unsafe anything anywhere. There are no particular pure Java library functions that are worth making an exception for. -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
On Fri, 31 May 2002, Manuel M. T. Chakravarty wrote: I think, the probelm is .NET, not Haskell. .NET just doesn't deliver on its promise (= marketing hype) of language neutrality. The problem is that .NET is language neutral only as long as all languages are sufficiently close to C#. Not just Haskell, but widely used languages like C++ run into this problem, too (see .NET's Managed C++). That may (or may not) be the case; I don't know. I was more wondering about `what really makes it so daunting for some working at a Microsoft (and who thus has more knowledge available about .NET than external people) to implement a Haskell for .NET, especially given the existance of F#?' One of the thoughts behind this was the knowledge that it's just the two Simons' at Microsoft Cambridge now maintaining/developing GHC; _if it were possible_ (and I'll quite concede it may not be) to leverage work on .NET for other purposes (particularly if .NET actually fulfills one of its `promises' to be OS neutral) to decrease the amount of work to keep one of the two Haskell remaining compilers (GHC, NHC) viable and up-to-date. ___cheers,_dave_ www.cs.bris.ac.uk/~tweed/ | `It's no good going home to practise email:[EMAIL PROTECTED] | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
D. Tweed [EMAIL PROTECTED] wrote, One of the thoughts behind this was the knowledge that it's just the two Simons' at Microsoft Cambridge now maintaining/developing GHC; _if it were possible_ (and I'll quite concede it may not be) to leverage work on .NET for other purposes (particularly if .NET actually fulfills one of its `promises' to be OS neutral) to decrease the amount of work to keep one of the two Haskell remaining compilers (GHC, NHC) viable and up-to-date. As I see it, .NET is just generating more work. I seriously doubt that the efficiency of a .NETed Haskell would be anywhere close to what GHC delivers today. This is judging from the various attempts to compile Haskell to JVM (sure there are some differences between JVM and .NET, but I am pretty sceptical that this will significantly close the gap). What we need is some seriously new technology. See http://www.cse.unsw.edu.au/~chak/project/poc/ for some ideas. Cheers Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
I wonder if ghc is the right place to start for H#/haskell.net / whatever? GHC is a (wonderfully) complex beast... it seems to have every feature anyone ever thought to add to haskell (esp in terms of the type system). Maybe one should start with haskell98 + ffi or whatever you need to add to get .net interop? Would that be easier? The problem is that ghc (seems) to be a research language aimed at playing with all kinds of possible type systems and such (which I am not saying is a bad thing..). Of course, I dont really know to much about how ghc is implemented... maybe the bits that do the fancy stuff is easy :) Cheers! Ron Haskell Fan. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: 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? General remarks about targetting .NET from GHC. * There is no reason in principle why one can't write a back end for GHC to generate .NET IL. * Generating *verifiable* IL is noticeably harder: you have to take much more care; to deal with parametric polymorphism you need Generic IL, which isn't out yet; and even then, higher kinded type variables are a serious problem. Being verifiable almost certainly requires some runtime checked type casts, which hurt performance -- and reducing them to a minimum complicates the compiler. * My conclusion: best plan is to generate unverifiable IL, and run it unverified. Situation is then just like an existing code generator: you have to trust the compiler. But it's fast and it's much simpler. * The resulting code will still run quite a bit slower than GHC-complied code. So why would anyone want to use it? Presumably, to get access to the .NET libraries. So that has to be very convenient. Tools are needed to read .NET library meta-data and generate impedence matching glue to make them easily callable from Haskell. Haskell needs some new 'foreign import' stuff to make it easy to call the libraries. There's a big design space here about how much to extend Haskell to make calling .NET convenient. * GHC supports concurrency, exceptions, weak pointers, foreign calls, etc, etc. All these need to be mapped onto .NET. Some might not fit well; for example, Concurrent Haskell assumes extremely lightweight concurrency, whereas .NET threads are OS threads; and asynchronous exceptions might be tricky too. * GHC comes with a large collection of libraries of its own. These need to be still available in the .NET version, so the .NET implementation of GHC needs to be pretty fully-featured (because the libraries use a lot of features). What all this means is that GHC.NET is a lot more than just a code generator. That is, I think, what Don meant when he said that GHC is complicated. (In our defence, it is the very fact that GHC is a rich system that makes it useful. Its complexity is not gratuitous.) Part of my reason for writing this is to encourage anyone out there to take up the challenge. There's nothing too difficult -- it's just work. Simon and I don't have immediate plans to do anything about this, but we'd be delighted if someone else did. Congratulations to Sigbjorn to doing a great job with Hugs. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Fwd: F#]
On 31-May-2002, Simon Peyton-Jones [EMAIL PROTECTED] wrote: General remarks about targetting .NET from GHC. * There is no reason in principle why one can't write a back end for GHC to generate .NET IL. * Generating *verifiable* IL is noticeably harder: you have to take much more care; to deal with parametric polymorphism you need Generic IL, which isn't out yet; You don't _need_ Generic IL. You can deal with parametric polymorphism by translating polymorphic types to System.Object. and even then, higher kinded type variables are a serious problem. I think System.Object helps here too. Being verifiable almost certainly requires some runtime checked type casts, which hurt performance -- and reducing them to a minimum complicates the compiler. It's certainly true that being verifiable is likely to cost some performance. But I don't think it would be difficult to implement. For the Mercury compiler's .Net back-end, there's a --verifiable option which controls whether the generated IL code is verifiable or not. -- Fergus Henderson [EMAIL PROTECTED] | I have always known that the pursuit The University of Melbourne | of excellence is a lethal habit WWW: http://www.cs.mu.oz.au/~fjh | -- the last words of T. S. Garp. ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
GHC supports concurrency, exceptions, weak pointers, foreign calls, etc, etc. All these need to be mapped onto .NET. ... GHC comes with a large collection of libraries of its own. These need to be still available in the .NET version. I don't really agree with these points. If someone tried to support all of this they'd be unlikely to appear out the other end of the swamp. Having actually tried both ways myself, I'd suggest that GHC is simply not the right starting point for a Haskell.NET compiler. Much better to start a fresh compiler, essentially from scratch, with a suitable selection of optimizations, language extensions, library features and interop extensions given the platform and kind of programming you're aiming to support. If you look at history successful compiler projects do not tend to some out of attempts to graft large code bases for alternative purposes (unless you've got loads of resources to throw at the problem). Cheers, Don -Original Message- From: Simon Peyton-Jones [mailto:[EMAIL PROTECTED]] Sent: 31 May 2002 15:31 To: Don Syme; D. Tweed Cc: Paul Hudak; haskell Subject: RE: [Fwd: 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? General remarks about targetting .NET from GHC. * There is no reason in principle why one can't write a back end for GHC to generate .NET IL. * Generating *verifiable* IL is noticeably harder: you have to take much more care; to deal with parametric polymorphism you need Generic IL, which isn't out yet; and even then, higher kinded type variables are a serious problem. Being verifiable almost certainly requires some runtime checked type casts, which hurt performance -- and reducing them to a minimum complicates the compiler. * My conclusion: best plan is to generate unverifiable IL, and run it unverified. Situation is then just like an existing code generator: you have to trust the compiler. But it's fast and it's much simpler. * The resulting code will still run quite a bit slower than GHC-complied code. So why would anyone want to use it? Presumably, to get access to the .NET libraries. So that has to be very convenient. Tools are needed to read .NET library meta-data and generate impedence matching glue to make them easily callable from Haskell. Haskell needs some new 'foreign import' stuff to make it easy to call the libraries. There's a big design space here about how much to extend Haskell to make calling .NET convenient. * GHC supports concurrency, exceptions, weak pointers, foreign calls, etc, etc. All these need to be mapped onto .NET. Some might not fit well; for example, Concurrent Haskell assumes extremely lightweight concurrency, whereas .NET threads are OS threads; and asynchronous exceptions might be tricky too. * GHC comes with a large collection of libraries of its own. These need to be still available in the .NET version, so the .NET implementation of GHC needs to be pretty fully-featured (because the libraries use a lot of features). What all this means is that GHC.NET is a lot more than just a code generator. That is, I think, what Don meant when he said that GHC is complicated. (In our defence, it is the very fact that GHC is a rich system that makes it useful. Its complexity is not gratuitous.) Part of my reason for writing this is to encourage anyone out there to take up the challenge. There's nothing too difficult -- it's just work. Simon and I don't have immediate plans to do anything about this, but we'd be delighted if someone else did. Congratulations to Sigbjorn to doing a great job with Hugs. Simon ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
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¥
Re: [Fwd: F#]
Don Syme [EMAIL PROTECTED] 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 JavaC# 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) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
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:[EMAIL PROTECTED] | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Fwd: F#]
Hey Simon et al at Micro$oft, when will there be an H#? But H# is C! we don't want that, surely? :-) Jón -- Jón Fairbairn [EMAIL PROTECTED] 31 Chalmers Road [EMAIL PROTECTED] Cambridge CB1 3SZ+44 1223 570179 (after 14:00 only, please!) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Fwd: F#]
Paul Hudak [EMAIL PROTECTED] writes: Hey Simon et al at Micro$oft, when will there be an H#? (Ok, I'll settle for Haskell.NET :-) There's hugs98.net and it's with us now: http://galois.com/~sof/hugs98.net/ --sigbjorn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
Hey Sigbjorn, that looks great! I'll look forward to trying it out. Perhaps when the source release is available someone could look at getting hugs98.net to be able to interop. with ILX components as well, making combined F#/hugs98.net apps feasible. I'm one who believe both Haskell and ML have their place :-) Best wishes, Don -Original Message- From: Sigbjorn Finne [mailto:[EMAIL PROTECTED]] Sent: 30 May 2002 16:21 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: [Fwd: F#] Paul Hudak [EMAIL PROTECTED] writes: Hey Simon et al at Micro$oft, when will there be an H#? (Ok, I'll settle for Haskell.NET :-) There's hugs98.net and it's with us now: http://galois.com/~sof/hugs98.net/ --sigbjorn ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
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:[EMAIL PROTECTED]] 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:[EMAIL PROTECTED] | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Fwd: F#]
Hi Don -- Thanks for all the informative stuff regarding FP implementations on .NET. However I am a little surprised by one thing you say: ... 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 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). -Paul ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
... 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
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'' ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: [Fwd: F#]
D. Tweed [EMAIL PROTECTED] wrote, 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.) I think, the probelm is .NET, not Haskell. .NET just doesn't deliver on its promise (= marketing hype) of language neutrality. The problem is that .NET is language neutral only as long as all languages are sufficiently close to C#. Not just Haskell, but widely used languages like C++ run into this problem, too (see .NET's Managed C++). Cheers, Manuel ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
