January 2005 - Haskell-Cafe

RE: [Haskell-cafe] Hugs vs GHC (again) was: Re: Some randomnewbiequestions
by Simon Marlow 08 Jan '05

08 Jan '05

On 07 January 2005 12:30, Malcolm Wallace wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> Here's a summary of the state of Unicode support in GHC and other >> compilers. There are several aspects: >> >> - Can the Char type hold the full range of Unicode characters? >> This has been true in GHC for some time, and is now true in Hugs. >> I don't think it's true in nhc98 (please correct me if I'm wrong). > > You're wrong :-). nhc98 has always had 32-bit characters internally. I checked the nhc98 sources, and it seems that maxBound::Char is '\255'. >> - Can you use (some encoding of) Unicode for your Haskell source >> files? I don't think this is true in any Haskell compiler right >> now. > > Many years ago, hbc claimed to be the only compiler with support for > this. What encoding(s) did hbc allow in source files? The docs only mention unicode characters inside character & string literals. Cheers, Simon

3 3

RE: [Haskell-cafe] Some random newbie questions
by Simon Peyton-Jones 08 Jan '05

08 Jan '05

| * As far as I can determine, there is no way to check pattern matches for | exhaustiveness. Coming from OCaml, this feels like losing a significant | safety net! How do people program so as not to be getting dynamic match | failures all the time? GHC has -fwarn-incomplete-patterns and -fwarn-overlapped-patterns. But the code implementing these checks is old and crufty, and the warnings are sometimes a bit wrong -- at least when guards and numeric literals are involved. I think they are accurate when you are just using "ordinary" pattern matching. Cleaning up this bit of GHC is a long-standing to-do item, if anyone feels motivated to undertake it. It's a well-defined task, with plenty of well-written papers explaining how to do it -- but it's tricker than it seems at first! Simon

3 2

RE: [Haskell-cafe] The implementation of Functional
by Simon Peyton-Jones 07 Jan '05

07 Jan '05

The online-readable copy is all ready to go. I'm just awaiting a final "ok" from Marnie and I'll announce it. For a paper copy we'll await John's Cafepress efforts. Much thanks to both Marnie and John. Simon | -----Original Message----- | From: haskell-cafe-bounces(a)haskell.org [mailto:haskell-cafe-bounces@haskell.org] On Behalf Of | robert dockins | Sent: 06 January 2005 19:22 | To: haskell-cafe | Subject: [Haskell-cafe] The implementation of Functional | | | The following discussion occurred last September. Is there any kind of | update on any version of this book? | | ----------------------------------------- | | John Meacham writes: | > > >I am looking for the book "The implementation of Functional | > > >Programming languages" by S. L. Peyton Jones. | | > > This book is out of print and currently there is no electronic version | > > of it. The Haskell bookstore folk are working on reconstructing it and | > > making it available for print-on-demand, | > > http://www.cafepress.com/haskell_books/, but it's not clear when | > > exactly it will be available. | > > | > > Your other option is to try to find a used copy, but they are pretty | > > expensive. | > | > I am working on getting that book available in the haskell bookstore. I | > searched quite a while before I found a used printed copy at a | > reasonable price and my search was part of my motivation for creating | > the bookstore. | > | > It is a bit trickier than the other books on the site because I only | > have a scanned in copy of the print version to work with, rather than | > LaTeX source. but I should have time this week to get it online. | > John | | My wife (mainly) and I, with Simon's permission, have been working on | getting a web-enabled version of this available for quite some time. It | hovers on the brink of completion, and should be there Real Soon Now as | well. This will include a web enabled table of contents and next and back | buttons. | | If I'd known how much time she would put in, I'd have never asked her for "a | small favor"....... | | Dave Barton | EDAptive Computing | | _______________________________________________ | Haskell-Cafe mailing list | Haskell-Cafe(a)haskell.org | http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0

Some random newbie questions
by Derek Elkins 07 Jan '05

07 Jan '05

> OK, I'm taking the plunge and using Haskell in a course I'm teaching > this semester. To get ready, I've been doing quite a bit of Haskell > programming myself, and this has raised a few questions... > > * What are the relative advantages of Hugs and GHC, beyond the obvious > (Hugs is smaller and easier for people not named Simon to modify, > while GHC is a real compiler and has the most up-to-date hacks to > the type checker)? Do people generally use one or the other for > everything, or are they similar enough to use Hugs at some moments and > GHC at others? All the below is my personal opinion: My impression is that GHC is by far the most used Haskell implementation. In my opinion, the only reason Hugs should be used is if it's the only implementation that will run on your system, otherwise GHC or NHC will likely make a better choice. Some of the differences between GHC and the last version of Hugs I've looked at are: 1) GHCi views it's repl as being in a do-block, with the most important consequence being the ability to define functions interactively, Hugs views the input as an expression so functions can only be defined locally. Neither are rather impressive interactive environments (not when compared to Squeak or CL listeners), but GHCi's is definitely more convenient. 2) GHC is generally acknowledged to do a (significantly) better job with error messages (both type and run-time errors). To me, the difference is so significant that, all other things being equal, GHC would still win hands-down. 3) Most development of third-party libraries and tools target GHC first, part of that has to do with 4) Beyond enhancements to type checking, GHC has many other extensions such as: template haskell, preemptive concurrency (Hugs does have cooperative concurrency), asynchronous exceptions, built-in arrow notation, support for generics, and more. 5) And of course, (3) is also caused by second order effects of itself, e.g. Yi uses GHC because it uses hs-plugins which is intimately related to GHC. 6) GHC has support for profiling.

1 0

The implementation of Functional
by robert dockins 07 Jan '05

07 Jan '05

The following discussion occurred last September. Is there any kind of update on any version of this book? ----------------------------------------- John Meacham writes: > > >I am looking for the book "The implementation of Functional > > >Programming languages" by S. L. Peyton Jones. > > This book is out of print and currently there is no electronic version > > of it. The Haskell bookstore folk are working on reconstructing it and > > making it available for print-on-demand, > > http://www.cafepress.com/haskell_books/, but it's not clear when > > exactly it will be available. > > > > Your other option is to try to find a used copy, but they are pretty > > expensive. > > I am working on getting that book available in the haskell bookstore. I > searched quite a while before I found a used printed copy at a > reasonable price and my search was part of my motivation for creating > the bookstore. > > It is a bit trickier than the other books on the site because I only > have a scanned in copy of the print version to work with, rather than > LaTeX source. but I should have time this week to get it online. > John My wife (mainly) and I, with Simon's permission, have been working on getting a web-enabled version of this available for quite some time. It hovers on the brink of completion, and should be there Real Soon Now as well. This will include a web enabled table of contents and next and back buttons. If I'd known how much time she would put in, I'd have never asked her for "a small favor"....... Dave Barton EDAptive Computing

2 1

urls
by Tristan Wibberley 07 Jan '05

07 Jan '05

http://research.microsoft.com/Users/simonpj/papers/assoc-types/index.htm http://www.haskell.org/hawiki/GHC_206_2e4

1 1

Begginer question
by Maurício 07 Jan '05

07 Jan '05

Hi, When compiling this: ************ import Complex; complex_root :: (Float, Float, Float) -> (Complex Float, Complex Float) complex_root (a,b,c) = (x1,x2) where { delta = b * b - 4 * a * c :: Float; sqr_delta = if delta >= 0 then (sqrt delta) :+ 0 else 0 :+ (sqrt delta) :: (Complex Float); x1 = (b + sqr_delta)/(2 * a); x2 = (b - sqr_delta)/(2 * a); } *********** I get this error message: ********** Couldn't match `Float' against `Complex Float' Expected type: Float Inferred type: Complex Float In the second argument of `(+)', namely `sqr_delta' In the definition of `x1': x1 = (b + sqr_delta) *********** Can you help me finding what is wrong? Shouldn't "b" be converted to Complex Float and be summed to sqr_delta? Thanks for your help, Maurício

5 7

RE: [Haskell-cafe] Seeking comments on this IO proposal
by Simon Marlow 06 Jan '05

06 Jan '05

On 17 December 2004 16:49, John Goerzen wrote: > First, if someone were to make a working, useful package out of this, > is it likely that it would become the "standard" (whatever that > means) IO system in Haskell anytime in the near future? I ask > because I don't want to put a lot of time into developing an IO > library, and code that works with it, only to have nobody use my code > because it's incompatible with everything they're doing. I'm keen to transition over to a more general IO framework, and I believe Bens/my proposal is heading in the right direction. When we have a more complete implementation, I'd be happy to include it with GHC for experimentation, and over time transition code to use the new framework while leaving the old System.IO in place for the time being. The design isn't by any means set in stone at this stage though. > Second is my own level of expertise. I frankly don't understand how > much of that code could even compile (example: I couldn't find > setNonBlockingFD anywhere in my docs; maybe it's from one of those > GHC.* areas), and I don't really understand the whole array/buffer > situation either. I spent some time reading docs, and I'm still not > sure exactly how one builds a mutable, resiable array. I've also > never done anything but the most trivial FFI work. Much of the reason for the complexity is because I was paying careful attention to performance (perhaps too much attention). I don't want the addition of a text encoding/decoding layer to the IO subsystem to affect performance more than is necessary, and that means doing the translation on raw character buffers rather than strings. Unfortunately this does mean that porting to other compilers is going to be more work. Cheers, Simon

1 0

RE: [Haskell-cafe] Re: Utility functions
by Simon Marlow 06 Jan '05

06 Jan '05

On 06 January 2005 12:20, Ketil Malde wrote: > "Simon Marlow" <simonmar(a)microsoft.com> writes: > >> There are already a couple of bits of (L)GPL under fptools: GMP and >> readline. GMP we'd like to replace because it is necessarily a part >> of every compiled Haskell program; readline isn't so important but >> it would be nice to have a BSD-licensed replacement. > > Readline is GPL and GMP LGPL, aren't they? Yes. > So GMP only restricts > what you can do with modifications to that library (and thus only > affects developers who want to release a modified GHC without source), > while linking with readline will potentially affect regular users of > GHC. Strictly speaking you have to dynamically link GMP to avoid your program being affected by the LGPL. Most GHC installations use a dynamically linked GMP, but some do not. Readline's license affects GHC (because GHC itself links with it), but it doesn't affect programs you compile with GHC unless you explicitly request the readline package (unlike GMP, which is always linked in). Cheers, Simon

1 0

RE: [Haskell-cafe] Re: Utility functions
by Simon Marlow 06 Jan '05

06 Jan '05

On 30 December 2004 05:25, Philippa Cowderoy wrote: > On Wed, 29 Dec 2004, John Goerzen wrote: > >> But like I've said, I am willing to negotiate with people that >> require code under a license that lets them use it without releasing >> the code. I have also stated that I will put any part of the code >> I've written under the fptools license if that code will be added to >> fptools. (I perceive that as a greater good than license pragmatism >> in this instance.) > > This is the bit I was worried about, the idea of GPLed library code in > fptools disturbs me somewhat. There are already a couple of bits of (L)GPL under fptools: GMP and readline. GMP we'd like to replace because it is necessarily a part of every compiled Haskell program; readline isn't so important but it would be nice to have a BSD-licensed replacement. The policy for Haskell libraries in fptools is that licenses are assigned no finer than package granularity, so that a user of a package can have a reasonable chance of telling whether they are complying with the relevant licenses. Cheers, Simon

2 1