- Haskell - Haskell.org

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

Re: fold on Monad?
by C.Reinke 30 May '02

30 May '02

> Suppose I have a task I want to do to each line of a file, > accumulate a result and output it, >.. > I'd like to write something similar to > > main = do res <- foldX process_line initial_value getLine > print res > I feel this ought to be straightforward -- the structure is > obviously some sort of fold, but I shouldn't have to use a > list -- so I must be missing something obvious. What is it? foldr, foldM, etc. derive a recursive computation from the recursive structure of an input list, so you have to feed one in. If you want to bypass the list, you could use IO-observations (getLine, isEOF) instead of list observations (head/tail, null): import IO foldX f c = catch (do l <- getLine r <- foldX f c return $ f l r) (\e->if isEOFError e then return c else ioError e) main = foldX (:) [] >>= print Whether that is a real fold, or what the real fold/unfold would look like, I leave to others;-) The same goes for optimization. Hth, Claus

3 3

[Fwd: F#]
by Paul Hudak 30 May '02

30 May '02

Hey Simon et al at Micro$oft, when will there be an H#? (Ok, I'll settle for Haskell.NET :-) -Paul

2 1