July 2002 - Glasgow-haskell-users

ANNOUNCE: GHC version 5.04 released
by Simon Marlow 19 Jul '02

19 Jul '02

============================================================ The (Interactive) Glasgow Haskell Compiler -- version 5.04 ============================================================ We are pleased to announce a new major release of the Glasgow Haskell Compiler (GHC), version 5.04. Highlights include: * Hierarchical libraries, with documentation produced by Haddock. * New type system extensions: full rank-N types and kind annotations. * New heap profiling facilities (retainer profiling, biographical profiling). * MacOS X support See the release notes for a full list of the changes: http://www.haskell.org/ghc/docs/latest/html/users_guide/release-5-04.htm l 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.bz2 which can be installed wherever you want. The source distribution is also available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, come back later. 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/html/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.

6 6

DeepSeq
by George Russell 19 Jul '02

19 Jul '02

Would it be possible to bring the DeepSeq library into the libraries distributed with GHC? (I think Dean Herington is responsible for it.) Of course it's easy enough to drop it into one's own program (I am just about to do this) but (1) It is fairly common to want to force deeper evaluation. (2) DeepSeq is simple enough to be dropped in the GHC distribution, without it causing much trouble or making it much bigger. (3) At the same time, it is not so simple that it can be reimplemented in a couple of lines.

4 4

Re: ANNOUNCE: GHC version 5.04 released
by George Russell 19 Jul '02

19 Jul '02

There are now also binary bundles of HTk for ghc5.04 on Linux, Windows and Solaris. So you can write GUIs in ghc5.04. Available from http://www.informatik.uni-bremen.de/htk

3 3

RE: ANNOUNCE: GHC version 5.04 released
by Simon Marlow 19 Jul '02

19 Jul '02

> > Can we expect ghc-5.04 SuSE rpms soon? > > Thanks. > > > > J.A. > > Sorry. I've simply forgotten to announce them. The following > RPMs were built under SuSE 8.0. These are now available from the GHC download page. Thanks Ralf! Cheers, Simon

1 0

CHAT AND SEXSCHOOL LIVE
by LECCORNIA 18 Jul '02

18 Jul '02

http://www.ragazze-sexy.tv nuova chat multitasking con multiriprese nuova area interna per lezioni di sesso live nuova sezione per allungamento del pene tutto manuale 100% naturale nuove chattiste mai viste in rete http://www.ragazze-sexy.tv La Tua email � stata rilasciata sui nostri portali se non vui pi� ricevere news scrivi a deletemail(a)libero.it

1 0

fno-implicit-prelude and literal numeric patterns
by Bernard James POPE 18 Jul '02

18 Jul '02

Hi again, I know I'm becoming a pest with this, but another question about -fno-implicit-prelude: What happens with literal numeric patterns? For this part of the prelude: gcd :: (Integral a) => a -> a -> a gcd 0 0 = error "Prelude.gcd: gcd 0 0 is undefined" gcd x y = gcd' (abs x) (abs y) where gcd' x 0 = x gcd' x y = gcd' y (x `rem` y) I'm getting this error (which refers to the transformed version of the code of course but I don't think the transformation has anything to do with it). Prel_Buddha.hs:459: Could not deduce (GHC.Base.Eq a) from the context (Integral a) Probable fix: Add (GHC.Base.Eq a) to the type signature(s) for `gcd' arising from the pattern `0' at Prel_Buddha.hs:459 When checking the pattern: (0, 0) In a case alternative: (0, 0) -> error "Prelude.gcd: gcd 0 0 is undefined" I'm sure my version of class Integral, Real, Num, Eq is the same as the example Prelude from the Language Report. I'm still using 5.03, perhaps it has changed in 5.04? (My apology if it has - it turns out to be quite hard for me to test in 5.04 because my transformation doesn't uses the old convention with desugaring do notation ...) If I get rid of the literal numeric patterns the error disappears. Cheers, Bernie.

1 0

RE: package name mismatch
by Simon Marlow 18 Jul '02

18 Jul '02

> Simon Marlow wrote: > > > > > It must have been only a warning in 5.02.3, or I could never have > > > compiled it there. (Before 5.02.3 we didn't use the package > > > system like this at all.) > [snip] > > > > Can't you just fix your build so that the situation doesn't occur? > [snip] > In fact I have been unable to reproduce the problem with > ghc5.04 anyway. > My guess would be that GHC now searches the package > directories before the > current directory. So we're all happy, unless someone wants > to override a > module in an imported package. Even then a better solution > would be to > write another package containing the altered module, and put > it first in > the search path. > > Is the order in which GHC looks for imported modules > specified anywhere? No, but our position is that you shouldn't have more than one module with the same name, regardless of whether they are in separate packages or not, and that the import path for the home package should not overlap with the import path for any other package. The only exception is perhaps two packages that aren't intended to be used together. Cheers, Simon

1 0

Re: replacing the Prelude (again)
by Bernard James POPE 18 Jul '02

18 Jul '02

Dylan writes: > On Tue, Jul 16, 2002 at 04:02:44PM +1000, Bernard James POPE wrote: > > I would like to use do-notation in the transformed program, but have it > > refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. > > Why do you have a MyPrelude.Monad (different from Prelude.Monad) if > you don't want to use it? Hi, This is part of a debugger for haskell. The approach taken is to transform the original program. Under transformation the types of functions change. If the user's program calls >>=, then in the debugged program that is a call to a transformed version of >>= (ie MyPrelude.Monad - don't worry it isn't really called "MyPrelude"). Btw all do notation from the original program is desugared during transformation. It just turns out that the transformed code is neater if I can use do notation in it. Which is quite helpful because it makes it easier to check that the transformation is doing the right thing! However, for this I have to use Prelude.Monad instead of MyPrelude.Monad, because the latter is transformed and all the types are changed. It really isn't a big deal. I can do without the do notation. I just have to change the transformation. If there were more fine grained control about how desugaring worked then that would help, but that would also add a lot of extra complexity to the compiler and I doubt the benefits would outweigh the costs. Cheers, Bernie.

1 0

Re: replacing the Prelude (again)
by Bernard James POPE 17 Jul '02

17 Jul '02

Malcolm writes: > Bernie writes: > > I did wonder how Hat tackled this. > > Out of curiosity what is the solution that Hat uses? > > Hat doesn't have a solution. When the lack of correct defaulting > causes Hat to generate type-incorrect code, the underlying compiler > will complain vociferously. Our advice to users is to write `default > ()' at the top of the module, then resolve the type errors they > get from the normal compilation so that defaulting is completely > eliminated. The code will then go through Hat smoothly. > > It isn't very satisfactory, but in practice, defaulting doesn't > really occur very often, so it isn't too much of a hardship. That was going to be my fallback strategy, I'm glad I'm not the only one! > > This adds an extra element of difficulty to the problem. I am trying > > my hardest to avoid needing the to import the original Prelude in > > a transformed module - this requires quite a bit of desugaring in the > > transformation. > > > > For what reasons do you require the original prelude? > > Exactly the same reasons. We want to do as little desugaring as > necessary in the transformation, so inevitably we need at least a > small part of the Prelude in scope. I would like to use do-notation in the transformed program, but have it refer to Prelude.Monad and not MyPrelude.Monad which is also in scope. The reason I mention this is that the behviour of -fno-implicit-prelude seems to have changed with respect to desugaring do notation, at least according to this post from Simon Peyton-Jones: http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003688.html In the upcoming 5.04 release you'll be able to do exactly that. GHC will use whatever >>= is in scope if you say -fno-implicit-prelude. Sure I can always get by without do notation, but the transformed program is then a lot uglier and harder to comprehend. Does hat work with ghc 5.04? Cheers, Bernie.

2 1

RE: package name mismatch
by Simon Marlow 17 Jul '02

17 Jul '02

> It must have been only a warning in 5.02.3, or I could never have > compiled it there. (Before 5.02.3 we didn't use the package > system like this at all.) > > Actually I would like this message to go away altogether in this case, > if possible. The actual situation is that GetPut.hs is in fact part > of the package "uni-events-test", and the compiler is told to load > uni-events-test on the command line. However GetPut.hs is *also* in > the current directory during this compilation, so GHC loads > it from there > instead. I'm not sure what logic would be best here, but my > suggestion > would be that where a .hi file is found in an import declaration and > has an unexpected package name, GHC keeps on searching. If it finds > a .hi file with a matching package name, it accepts it, otherwise > accept the .hi file with the wrong package name and issue a warning. > > If that's too complicated, just ignore .hi files with the > wrong package name. But then people might complain . . . I think this is all way too complicated. GHC's view of modules is fairly simple: they either reside in the home package or another package. If a module occurs in both, then previously it was an error, now it is just a warning. If we were using packages for dynamic libraries, one of the reasons we originally added packages, then it really *would* be an error and you'd be in trouble if you did this! Can't you just fix your build so that the situation doesn't occur? Cheers, Simon

2 2