Hi Paul, The attached message doesn't give the link you might be after, which is http://research.microsoft.com/projects/fsharp. You might also be interested in SML.NET. Re Haskell.NET... We (OK, basically just me) got a fair amount of the way through a .NET backend for GHC, including a fully working compiler, but we got sidetracked into implementation issues that weren't related what we wanted to achieve in the first instance. In particular, (a) GHC is a complex beast, (b) you have to decide what to do about the libraries and (c) I wanted a much "lighter" end system than GHC was 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#. Those of us at MSR have no particular plans to push further on Haskell.NET right now, but I know a number of other people have talked about taking a crack at it. Best wishes, Don Syme MSR Cambridge -----Original Message----- From: Paul Hudak [mailto:paul.hudak@yale.edu] Sent: 30 May 2002 14:12 To: haskell@cs.yale.edu Subject: [Fwd: F#] Hey Simon et al at Micro$oft, when will there be an H#? (Ok, I'll settle for Haskell.NET :-) -Paul
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:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh
"D. Tweed" <tweed@cs.bris.ac.uk> 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
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:tweed@cs.bris.ac.uk | a Special Outdoor Song which Has To Be work tel:(0117) 954-5250 | Sung In The Snow' -- Winnie the Pooh
"D. Tweed" <tweed@cs.bris.ac.uk> 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
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
participants (4)
-
D. Tweed -
Don Syme -
Manuel M. T. Chakravarty -
Ronald Legere