September 2002 - Haskell

ANNOUNCE: GHC version 5.04.1 released
by Simon Marlow 17 Sep '02

17 Sep '02

============================================================== The (Interactive) Glasgow Haskell Compiler -- version 5.04.1 ============================================================== We are pleased to announce a new patchlevel release of the Glasgow Haskell Compiler (GHC), version 5.04.1. This is a bugfix-only release. For all the changes since 5.02.3, see the release notes: http://www.haskell.org/ghc/docs/latest/users_guide/release-5-04.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the WWW page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for various flavours of Linux and BSD, and in InstallShield form for Windows folks. Binary builds for other platforms are available as a .tar.gz which can be installed wherever you want. The source distribution is also available from the same place. Once you have the distribution, please follow the pointers in the README file to find all of the documentation about this release. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language; the current language version is Haskell 98, agreed in December 1998. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ Haskell home page http://www.haskell.org/ comp.lang.functional FAQ http://www.cs.nott.ac.uk/~gmh/faq.html System requirements ~~~~~~~~~~~~~~~~~~~ To compile programs with GHC, you need a machine with 64+MB memory, GCC and perl. This release is known to work on the following platforms: * i386-unknown-{linux,*bsd,mingw32} * sparc-sun-solaris2 * alpha-dec-osf3 * powerpc-apple-darwin (MacOS/X) Ports to the following platforms should be relatively easy (for a wunderhacker), but haven't been tested due to lack of time/hardware: * hppa1.1-hp-hpux{9,10} * i386-unknown-solaris2 * mips-sgi-irix{5,6} * {rs6000,powerpc}-ibm-aix The builder's guide on the web site gives a complete run-down of what ports work; it can be found at http://www.haskell.org/ghc/docs/latest/building/building-guide.html Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Please report bugs using our SourceForge page at http://sourceforge.net/projects/ghc/ or send them to glasgow-haskell-bugs(a)haskell.org. GHC users hang out on glasgow-haskell-users(a)haskell.org. Bleeding edge CVS users party on cvs-ghc(a)haskell.org.

4 4

deriving Enum vs. deriving Bounded
by Johannes Waldmann 17 Sep '02

17 Sep '02

What is the rationale for not allowing `deriving Enum' for data types with a single unary constructor; while `deriving Bounded' is allowed in this case. Oh I see, deriving Bounded is allowed even for a single k-ary constructor, but the Report probably didn't want to fix an order of enumeration for the argument tuples. But then, why is `deriving Ord' allowed in this case :-) as it also refers to the fixed order of arguments. I don't intend to change anything here, I just want to understand the decision made in the Report. I'm sure this issue (and many others) must have been discussed - are the arguments archived somewhere? Best regards, -- -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ -- -- joe(a)informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --

2 1

terminology
by Richard Uhtenwoldt 16 Sep '02

16 Sep '02

consider an ordinary state monad that we've seen 1000 times: newtype StateTrans s a = ST( s -> (s, a) ) instance Monad (StateTrans s) where (ST p) >>= k = ST( \s0 -> let (s1, a) = p s0 (ST q) = k a in q s1 ) return a = ST( \s -> (s, a) ) now Haskell is an applicative language in which every expression has a value. the value of the expression return 3 is unprintable. it is a newtype whose representation is a function. I need a term for the 3. that is, I need a name for the variable a above. unless someone suggests a better name or knows of a name already in the literature, I'm going to call 3 the "oblique value" of the expression return 3.

2 1

Link on your website
by Pohlig 14 Sep '02

14 Sep '02

Hello, I am a German teacher in a Gymnasium (similar to a High School) I want to teach my pupils a little bit Haskell using hugs. My lessons will be published in the internet www.pohlig.de -> Einführung in Haskell. I would like to set a link onto your website using the lamda-icon. I would like to ask if is allowed to use this icon? Sincerely Michael Pohlig Schaafweide 21 76467 Bietigheim 07245 1248 michael(a)pohlig.de www.pohlig.de

1 0

FW: Labelled field restrictions
by Garner, Robin 13 Sep '02

13 Sep '02

Given data T = T { x,y::Int } data S = S { x,y::Int } f :: S -> T f s = T { x = S.y s, y = S.x s } Within the braces, the x and y on the LHS of the "="s are clearly field labels of the type being constructed and so shouldn't need qualification, and as above the x and y functions of S need to be qualified, as you write. My suggestion is that an unqualified x or y on the rhs could be implicitly taken to be the corresponding function of T. ie in g :: S -> T -> T g s t = t{ x = S.y s, y = x t } would mean g s t = t{ x = S.y s, y = T.x t } I think any confusion in the programmer's mind about which "x" is intended would lead to a type error, so the improved readability seems worthwhile. Robin -----Original Message----- From: Simon Peyton-Jones To: Garner, Robin; haskell(a)haskell.org Sent: 13/09/02 17:32 Subject: RE: Labelled field restrictions ... Also if I have data T = T { x,y::Int } data S = S { x,y::Int } I might write f :: S -> T f s = T { x = S.y s, y = S.x s } So just because I'm inside a T construction doesn't mean that "x" or "y" are unambiguous. Simon -----Original Message----- From: Garner, Robin [mailto:Robin.Garner@crsrehab.gov.au] Sent: 13 September 2002 01:57 To: 'haskell(a)haskell.org' Subject: Labelled field restrictions One Haskell limitation that has always puzzled me (and other programmers I have spoken with) is why labels in labelled fields share the top level name space. In practice his means that you generally name fields with some combination of constructor or type name and a field name, eg > data Rec = Con { recField1 :: Type, recField2 :: Type ... }. Is there a good reason why field labels couldn't be optionally qualified by the type name, and usable unqualified if they are unique in the current scope ? This would be consistent with the naming rules for other top-level names, just slightly more modular. In essence, the language would implicitly do what most programmers do already, but making life easier where possible. For example, given the declarations > data Type1 = Con1 { field1 :: Type11, field2 :: Type12 } > data Type2 = Con2 { field1 :: Type21, field3 :: Type22 } field2 and field3 could be used unqualified, but field1 would need to be referred to as Type1.field1 or Type2.field1 to disambiguate them. Additionally, within a construction using field labels (ie an x{ field = value , ...} construct), labels local to the type of x could be used unqualified as selector functions (ie in value expressions). Field names on the left-hand side of bindings would not need qualification. Essentially, the scope of the type being constructed would take priority inside the {...}. Labels from other types that clash with named labels in the local type would need to be explicitly qualified by the type name. As far as I can see, this extension wouldn't break any existing programs, but would simply complicate symbol resolution in the compiler somewhat. Robin Garner A.N.U.

1 0

RE: Labelled field restrictions
by Simon Peyton-Jones 13 Sep '02

13 Sep '02

A perfectly sensible idea. Main difficulty I see: it's not clear what T.x would mean if both type T and module T existed, though. Also if I have data T = T { x,y::Int } data S = S { x,y::Int } I might write f :: S -> T f s = T { x = S.y s, y = S.x s } So just because I'm inside a T construction doesn't mean that "x" or "y" are unambiguous. Simon -----Original Message----- From: Garner, Robin [mailto:Robin.Garner@crsrehab.gov.au] Sent: 13 September 2002 01:57 To: 'haskell(a)haskell.org' Subject: Labelled field restrictions One Haskell limitation that has always puzzled me (and other programmers I have spoken with) is why labels in labelled fields share the top level name space. In practice his means that you generally name fields with some combination of constructor or type name and a field name, eg > data Rec = Con { recField1 :: Type, recField2 :: Type ... }. Is there a good reason why field labels couldn't be optionally qualified by the type name, and usable unqualified if they are unique in the current scope ? This would be consistent with the naming rules for other top-level names, just slightly more modular. In essence, the language would implicitly do what most programmers do already, but making life easier where possible. For example, given the declarations > data Type1 = Con1 { field1 :: Type11, field2 :: Type12 } > data Type2 = Con2 { field1 :: Type21, field3 :: Type22 } field2 and field3 could be used unqualified, but field1 would need to be referred to as Type1.field1 or Type2.field1 to disambiguate them. Additionally, within a construction using field labels (ie an x{ field = value , ...} construct), labels local to the type of x could be used unqualified as selector functions (ie in value expressions). Field names on the left-hand side of bindings would not need qualification. Essentially, the scope of the type being constructed would take priority inside the {...}. Labels from other types that clash with named labels in the local type would need to be explicitly qualified by the type name. As far as I can see, this extension wouldn't break any existing programs, but would simply complicate symbol resolution in the compiler somewhat. Robin Garner A.N.U.

3 2

CFP -- EACL'03, Budapest
by Claire Gardent 13 Sep '02

13 Sep '02

* CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** EACL 2003 11th Conference of the European Chapter of the Association for Computational Linguistics April 12-17, 2003 Budapest, Hungary EACL03 invites submissions as follows: Main conference papers Registration deadline: 10 November Submission deadline: 15 November Research notes and Demos Registration deadline: 01 December Submission deadline: 06 December Student workshop Deadline: 15 November Tutorials Deadline: 15 November Workshops Deadline: 01 October *** FURTHER INFORMATION **** EACL03: http://www.conferences.hu/EACL03/ EACL: http://www.eacl.org EACL03 Student Workshop http://www.coli.uni-sb.de/conf/eacl03-student/ *** ORGANISATION **** Programme Co-Chairs Ann Copestake (United Kingdom) Jan Hajic (Czech Republic) Research notes and Demos Chair Alberto Lavelli (Italy) Tutorial Chair Dan Cristea (Romania) Publication Chair Patrick Paroubek (France) Workshop Chair Steven Krauwer (The Netherlands) Student workshop Chair EACL Student Board (M. Gabsdil, J. Hockenmaier, J. Herring) Local Organisation Chair: Ferenc Kiefer (Hungary) * CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP ** CFP **

1 0

Labelled field restrictions
by Garner, Robin 13 Sep '02

13 Sep '02

One Haskell limitation that has always puzzled me (and other programmers I have spoken with) is why labels in labelled fields share the top level name space. In practice his means that you generally name fields with some combination of constructor or type name and a field name, eg > data Rec = Con { recField1 :: Type, recField2 :: Type ... }. Is there a good reason why field labels couldn't be optionally qualified by the type name, and usable unqualified if they are unique in the current scope ? This would be consistent with the naming rules for other top-level names, just slightly more modular. In essence, the language would implicitly do what most programmers do already, but making life easier where possible. For example, given the declarations > data Type1 = Con1 { field1 :: Type11, field2 :: Type12 } > data Type2 = Con2 { field1 :: Type21, field3 :: Type22 } field2 and field3 could be used unqualified, but field1 would need to be referred to as Type1.field1 or Type2.field1 to disambiguate them. Additionally, within a construction using field labels (ie an x{ field = value , ...} construct), labels local to the type of x could be used unqualified as selector functions (ie in value expressions). Field names on the left-hand side of bindings would not need qualification. Essentially, the scope of the type being constructed would take priority inside the {...}. Labels from other types that clash with named labels in the local type would need to be explicitly qualified by the type name. As far as I can see, this extension wouldn't break any existing programs, but would simply complicate symbol resolution in the compiler somewhat. Robin Garner A.N.U.

1 0

Re: Labelled types question
by Sigbjorn Finne 12 Sep '02

12 Sep '02

Andre W B Furtado awfurtado(a)homelink.com.br writes: > > > Suppose I have a labelled type 'A' defined like the following one: > > module Test ( > A (b) > ) > > where > > data A = A > { b :: Int, > c :: Int > } > > I am exporting only 'A(b)', so why the following code "can see" 'c' ? > .... Hi, I'm guessing you're using the current release of Hugs. It doesn't implement the Haskell98 module system really, but the upcoming release does, making your code snippet behave as expected (from a H98 POV.) hth --sigbjorn

2 1

Re: GPH: RE: Concurrency and Haskell
by Phil Trinder 12 Sep '02

12 Sep '02

Murray, There are several parallel Haskell implementations: a survey of them has just appeared in Journal of Func. Prog Vols 4&5 (July & Sept 2002). Implementations are available for o Eden http://www.mathematik.uni-marburg.de/inf/eden/ o GpH http://www.cee.hw.ac.uk/~dsg/gph/ My group works on Glasgow parallel Haskell (GpH) which extends Haskell 98 with a parallel composition combinator. As Simon said the main implemntation, GUM, buys portability using the relatively slow PVM communications library. This doesn't matter so much on distributed memory machines, and we've recently achieved some quite respectable results SunServer shared-memory machines. Simon Marlowe developed an alternative SMP implementation of GpH a couple of years ago that may be more suitable for a Mosix platform, but I'm not sure of the status of that implementation now. Phil On Mon, 19 Aug 2002 18:04:44 +0100 Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > Hi Murray > > I'm catching up with my email backlog, but I didn't see a reply to your > message, so I thought I'd reply. The parallel-Haskell crew are at > http://www.cee.hw.ac.uk/~dsg/gph/ > There's a mailing list that I'm ccing. > > GHC can be built to run on a shared-memory multiprocessor, but we have > not built and tested that for some time. Untrue - both Eden and GpH are currently used on SunServer SMPs. > GPH is aimed more at > distributed-memory machines, and has quite a bit more code layered on > top of GHC. Details on the GPH page above. > > Let me know if I can help. It'd be great to get some more > parallel-Haskell stuff going. > > Simon > > | A group of us at Brooklyn College (City University of New > | York) are in the latter stages of setting up a Mosix cluster > | that we would like to use for research on, among other > | things, parallel execution of Haskell code and run-time > | optimization of both automatic and programmed parallelization. > | > | I would greatly appreciate hearing from anyone who can > | provide advice on > | an appropriate bibliography on the language implementation and past > | work in this area (other than the code in the Haskell compilers and > | libraries, of course), approaches, ongoing work, etc. > | > | Also, I would be most interested in hearing from anyone > | interested in joining our effort (no problems with remote > | access to the cluster by way of SSH), or making arrangements > | for cooperation in research in this area, although, of > | course, access to our equipment will be subject to approval > | from "higher authorities" (however, note that I really don't > | expect difficulty here, since our administration has already > | shown considerable interest in supporting the project). > | > | Replies to the list will be read, but those who wish may mail > | me directly at mgross(a)dorsai.org. > | > | Thanks in advance for any replies. > | > | Murray Gross > | Adj. Lecturer, Brooklyn College, > | City University of New York > | > | > | > | _______________________________________________ > | Haskell mailing list > | Haskell(a)haskell.org http://www.haskell.org/mailman/listinfo/haskell > | > -------------------------------------------------- Phil Trinder Department of Computing and Electrical Engineering Heriot Watt University Riccarton Edinburgh, EH14 4AS E-mail: trinder(a)cee.hw.ac.uk Teleph: +44 (0)131 451 3435 Depart: +44 (0)131 451 3328 Fasmly: +44 (0)131 451 3327 Intrnt: http://www.cee.hw.ac.uk/~trinder

4 7