May 2002 - Haskell - Haskell.org

RE: [Fwd: F#]
by Simon Peyton-Jones 31 May '02

31 May '02

| 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

2 1

RE: [Fwd: F#]
by Don Syme 31 May '02

31 May '02

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(a)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

4 5

Re: layout rule infelicity
by George Russell 31 May '02

31 May '02

I like layout but I think the existing rules are too complicated. Unfortunately it's difficult to do anything with them without breaking vast swathes of existing code, so we'll just have to put up with them. The reason I think layout is better than using {'s and ,'s is that humans use the layout to group the structure anyway, which means you can have confusing situations where a structure looks alright to a human but not to a computer.

5 6

�𾴵��Ͽͻ��
by syhua3000 31 May '02

31 May '02

�𾴵��Ͽͻ�� ã� ��(www.9dns.net)Ϊ�˴�л��Լ��ͻ��˾��֧�ֺ��Σ��ٴ��¾ɷ��ܣ��վ�ռ��졢�� ȶ��ȫ��ͬʱ��ǻ��˲�Ʒ �۸��ܸ��ʵķ��񡣣��˾��վ��ȫ�¸İ棺www.9dns.net�� 200M HTML�ռ�+1��۸�150Ԫ/�� 100M�ռ�(֧��ASP)+100M��ҵ�ʾ�+20M ACCESS��ݿ�+1�� 288Ԫ/�� 200M�ռ�(֧��ASP)+200M��ҵ�ʾ�+30M Access��ݿ�+1�� 338Ԫ/�� ֻ��ۼ۸񡣻�ӭѡ��Ҳ��ӭ��Ϊ��ǵĴ��! ��ǻ��и��Żݼ۸�� http://www.9dns.net �� 缼��޹�˾ --------------------------------------------------------------- �е�Ⱥ��ʼ�,��ר��(http://www.21cmm.com) ��CMM��У(http://www.21cmm.com)��Ŀ��ר��

1 0

Re: layout rule infelicity
by Ashley Yakeley 31 May '02

31 May '02

At 2002-05-30 02:26, Jon Fairbairn wrote: >I think this is extremely bad language design! In general I >like having layout rules, but ... What's the deal with the whole "layout" thing anyway? I've never come across it before in another language. Is it an academic thing? It drove me nuts when I first started Haskell, until I discovered you could use semicolons/braces instead (which I always do). If I were teaching Haskell to "working programmer" types like myself, I would encourage them to always use full semicolons and braces and forget layout entirely (except a lot of available Haskell source seems to use it). Certainly I find {;} more readable, and I suspect anyone else with a C/C++/Java background (or even a Scheme/Lisp background) does too.</RANT> -- Ashley Yakeley, Seattle WA

8 8

RE: [Fwd: F#]
by Don Syme 31 May '02

31 May '02

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:tweed@compsci.bristol.ac.uk] 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: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

3 2

Thesis on efficiently Eager Haskell
by Jan-Willem Maessen 30 May '02

30 May '02

My dissertation, "Hybrid Eager and Lazy Evaluation for Efficient Compilation of Haskell", is now available on the web: http://www.csg.lcs.mit.edu/~earwig/thesis.html Abstract (1st paragraph only): The advantage of a non-strict, purely functional language such as Haskell lies in its clean equational semantics. However, lazy implementations of Haskell fall short: they cannot express tail recursion gracefully without annotation. We describe resource-bounded hybrid evaluation, a mixture of strict and lazy evaluation, and its realization in Eager Haskell. From the programmer's perspective, Eager Haskell is simply another implementation of Haskell with the same clean equational semantics. Iteration can be expressed using tail recursion, without the need to resort to program annotations. Under hybrid evaluation, computations are ordinarily executed in program order just as in a strict functional language. When particular stack, heap, or time bounds are exceeded, suspensions are generated for all outstanding computations. These suspensions are re-started in a demand-driven fashion from the root. I'm presently working hard on making a production-quality version of the Eager Haskell compiler. If you have any questions about Eager Haskell, or would like to see a pre-release version of the compiler along with the programs I used as benchmarks, drop me a line. A full release of the unified pH / EH compiler is slated for mid-August. -Jan-Willem Maessen

1 0

RE: [Fwd: F#]
by Don Syme 30 May '02

30 May '02

> > ... 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

1 0

RE: [Fwd: F#]
by Don Syme 30 May '02

30 May '02

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:sof@galois.com] Sent: 30 May 2002 16:21 To: haskell(a)haskell.org Cc: paul.hudak(a)yale.edu Subject: Re: [Fwd: F#] Paul Hudak paul.hudak(a)yale.edu 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 Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell

1 0

Re: [Fwd: F#]
by Sigbjorn Finne 30 May '02

30 May '02

Paul Hudak paul.hudak(a)yale.edu 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

1 0