May 2008 - Glasgow-haskell-users

ANN: ghc 6.8.2 from MacPorts
by Gregory Wright 06 May '08

06 May '08

After what many would consider an unconscionable delay, I am happy to announce that ghc 6.8.2 is available from MacPorts. The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ intel. Users with Leopard/ppc are out of luck until for now, for reason discussed earlier on this list. In partial recompense for their patience, users will get a ghc with more patches than any previous MacPorts ghc. A few notes: The file locking bugs #1992 and #2134 are fixed. Bug #1992 was a simple lock logic error and should be killed dead. Bug #2134 was the result of a lazy readFile holding a lock for an unpredictable time. There may be more cases like this one, and I would appreciate a note from anyone who come across a lock error during building. Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug which under unusual circumstances would repeatably (and mysteriously) crash the build. This was first noticed running the building in an eshell under Aquamacs. Archives were built without tables of contents because ranlib wasn't being run or wasn't running to completion. Builds in the usual Terminal.app didn't trip over this bug. OpenGL support is built by default. It can be turned off using the no_opengl variant. OpenAL support is disabled. Apple's OpenAL framework lacks ALUT support (needed for the ghc binding) but has name clashes with the freealut library from the OpenAL.org website. Fixing this is probably straightforward. If someone is interested, I can give them some pointers on getting started. MacPort's ghc ought to always link with the correct libgmp (the one provided by the gmp port). The latest versions of alex, happy, haddock and hs-Edison are also available. Best Wishes, Greg

10 20

Warnings about unused variables or imports
by Simon Peyton-Jones 06 May '08

06 May '08

[Moving to GHC users: this thread concerns GHC's warning messages about unused things.] | But there are a few other inconvenient behaviors related only to | warnings, for instance | | module A where | foo x = x | | module B(foo) where | import A | | module C (module A, module B) where | import A | import B | | %> ghc --make C.hs -W: | | C.hs:1:20: Warning: `foo' is exported by `module B' and `module A' | | That's certainly true, but it's the same 'foo'. Just a warning of | course, and I'm not so sure I would argue that it shouldn't be there. | It's the same kind of warning as with any other multiple export of a | symbol I guess. But this pattern is not uncommon (in my code at | least), so the warning is inconvenient. Then again, that particular | warning can be turned off. Here the original intention was to warn about module C( foo, foo ) where... or perhaps module C( module A, foo ) where... but I agree that in the situation you describe the warning is silly. File a ticket for it? | Another, somewhat stranger, behavior: | | module A where | foo x = x | | module B(foo) where | import A | | module C(foo) where | import A | | module D () where | import B | import C | bar x = foo x | | %> ghc --make D.hs -W | | D.hs:2:0: | Warning: Module `B' is imported, but nothing from it is used, | except perhaps instances visible in `B' | To suppress this warning, use: import B() | | D.hs:3:0: | Warning: Module `C' is imported, but nothing from it is used, | except perhaps instances visible in `C' | To suppress this warning, use: import C() | | D.hs:4:0: Warning: Defined but not used: `bar' | | This might be said to be a bug, although it's a bug that would rarely | bite you, since it requires that 'bar' is not exported (or used in | something that is exported). If you export bar, then the warning talks | only of B - which is a rather arbitrary choice. There is something more substantial here. Suppose we have module Foo( g ) where import Bar( f4 ) f1 = f2 f2 = f3 f3 = f4 g = 7 At the moment GHC takes the view that f1,f2,f3,f4, and the import are *all* unused. If we said that just f1 was unused, then you'd delete it and get a new warning about f2; you delete that and get a new warning about f3; and so on. Yet the current behaviour is clearly confusing, even to a clued-up user, let alone a beginner. I'm starting to think that we should just do the obvious thing: report something as unused only if it physically does not occur. Any opinions? Your message also objects to arbitrarily choosing one of the imports as redundant. But if there are two imports import B import C and only one is needed, what would you like GHC to say? It's pretty hard to say "only one of these is needed", because it might be "of these three import declarations, you need 1&2 or 2&3 or 1&3". Simon

2 1

instance export decls
by Serge D. Mechveliani 03 May '08

03 May '08

Dear GHC developers, people, Do you agree that there exists such a problem for a programmer as recalling exported instances? Have Haskell and/or GHC some constructs and tools to help the programmer to recall the exported instances for a module? Could GHC support the instance export messages for each module? In Haskell-98, the exported instances cannot be named explicitly in the export list. Right? But for easier understanding of a program, it is desirable to allow to name (in a short form) instances in the export list. For this reason, I add comments, and write the export like this: module Poly (WithHead(..), WithTail(..), -- classes Mon(..), Polynomial(..), lc, polMons -- , instances -- for Mon: WithHead, List; -- for Polynomial: WithHead, Cast Polynomial Mon ) The comment of kind "-- , instances ..." helps to recall which instances are exported, without inspecting all the (lengthy) module source. But when the programmer changes the source, one often forgets to add/remove the needed comments about instances. I often forget them (maybe, lazy to recall) when I move pieces of code between modules. So, I suggest the following feature for GHC. 1. To allow the export declarations of kind instance {<type>} (maybe to suggest this for Haskell ?) 2. If the module under compilation has the word `instance' in its export list, then ghc finds the difference set diff for the exported instance kinds eKinds and the instance kinds nKinds named in the export list. If not $ null diff, it issues the message: "Warning: the exported instance kinds and the instance kinds named in the export differ in the following items: ...". Seeing such a message, the user corrects the export list in the source according to diff. For the export list and for their messages, it is probably better to use a short denotation: the instance kind rather than full instance declaration. In the instance kind, the part of "(...) =>" is skipped. What people think of this suggestion? Thank you in advance for your notes and help, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 4

RE: Unexpected lack of optimisation
by Simon Peyton-Jones 01 May '08

01 May '08

| The situation in Neil's code is almost identical, except that the | top-level case expression is on a value passed by environment, not by | function argument. Interesting thought. I think you're describing a possible extension to the SpecConstr transformation described in "Call pattern specialisation for Haskell" (http://research.microsoft.com/%7Esimonpj/papers/spec-constr) f x = let g y = ...case x of { z:zs -> e1; [] -> e2 } ... in ...case x of z:zs -> if ... then g 3 else g 4 [] -> ... Here 'x' is free in 'g', but x's value is known at g's call sites. It's not enough just to know "x is a cons" inside g; we must also have access to z,zs. So perhaps the thing to do is to imagine lambda-lifting 'g' to become 'gl' thus: gl x y = ...case x of { z:zs -> e1; [] -> e2 } ... f x = ...case x of z:zs -> if ... then gl x 3 else gl x 4 [] -> ... Now the SpecConstr transformation will apply nicely. And it's arguably a bad shortcoming that currently the mere act of lambda lifting can affect how effective SpecConstr is. Of course, we only want to lambda-lift wrt the parameters that'll be specialised, so this transformation probably wants to be done at the same time as the rest of SpecConstr. I don't have much idea of how hard that'd be, but it's a nice idea. Simon

2 1

installing all of hackage
by Duncan Coutts 30 Apr '08

30 Apr '08

All, We're getting nearer to being able to use cabal-install to install all of hackage for us. :-) I did a run this evening: $ cabal install -O0 $(cat pkgs) which is a list of 485 packages. I had to prune this list manually to eliminate the ones that have unsatisfiable dependencies (about 10). I hope to add a flag to get cabal-install to do that automatically, and where we do not use that flag, to produce better error messages saying *which* packages have the unsatisfiable dependencies. So I now have 329 library packages installed. It makes me notice this issue rather acutely: http://hackage.haskell.org/trac/ghc/ticket/2089 "reading the package db is slow" In fact this would be a really big problem for doing our own make-like system where we invoke ghc once for each module. Where at the moment it takes 1 second per library/executable, it'd take one second per module. It would in fact mean that reading the package database would take more time than compilation since compilation zips through at less than one second per module on average with -O0. I've also got a list of 163 install failures. Unfortunately we do not get logs of the failing packages, just a summary like: GuiTV-0.4 depends on wxcore-0.10.3 which failed to install. xtc-1.0 depends on wxcore-0.10.3 which failed to install. phooey-2.0 depends on wxcore-0.10.3 which failed to install. GenI-0.16.1 depends on wxcore-0.10.3 which failed to install. wx-0.10.3 depends on wxcore-0.10.3 which failed to install. AutoForms-0.4.0 depends on wxcore-0.10.3 which failed to install. wxcore-0.10.3 failed during the configure step. The exception was: exit: ExitFailure 2 Still, it's progress I feel. I've also added a flag to let us choose which version of the Cabal lib to use when building packages. This should make it possible to compare building everything with Cabal-1.2 and 1.4 for example. Duncan BTW, if you're wondering about the discrepancy in package numbers, it's because I had some packages installed already, some of which were not from hackage. Some of the packages I installed were binaries for which we do not track the installed state. Also, since some packages were already installed, cabal-install did not re-install them. So I don't know how many did actually install successfully, only how many failed.

1 0