July 2008 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

ANNOUNCE: GHC 6.8.3 Release Candidate
by Ian Lynagh 22 Sep '09

22 Sep '09

We are pleased to announce the Release Candidate phase for GHC 6.8.3. Snapshots beginning with 6.8.2.20080527 are release candidates for 6.8.3 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.2.20080527-src-extralib… Only the first of these is necessary. The "extralibs" package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team

8 13

ghci and ghc -threaded broken with pipes & forking
by John Goerzen 29 Dec '08

29 Dec '08

Hi, I've been hitting my head against a wall for the past couple of days trying to figure out why my shell-like pipeline code kept hanging. I found fd leakage (file descriptors not being closed), which disrupts EOF detection and can lead to deadlocks. I just couldn't find the problem. I finally tried compiling my test with ghc instead of running it in ghci. And poof, it worked fine the first time. I tried asking on #haskell, and got the suggestion that ghci uses -threaded. I tried compiling my test program with ghc -threaded, and again, same deadlock. My program never calls forkIO or forkOS or any other threading code. You can see my test case with: darcs get '--tag=glasgow ml' http://darcs.complete.org/hsh ghc -fglasgow-exts --make -o test2 test2.hs That'll run fine. If you add -threaded, it will hang. Ideas? Thanks, -- John

13 44

Arrow without `>>>'
by Valery V. Vorotyntsev 03 Sep '08

03 Sep '08

Hi, friends, I've built GHC from darcs, and... Could anybody tell me, what's the purpose of Arrow[1] not having `>>>' method? 1. http://darcs.haskell.org/packages/base/Control/Arrow.hs $ ghci GHCi, version 6.9.20080104: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. Prelude> :m + Control.Arrow Prelude Control.Arrow> :i Arrow class (Control.Category.Category a) => Arrow a where arr :: (b -> c) -> a b c pure :: (b -> c) -> a b c first :: a b c -> a (b, d) (c, d) second :: a b c -> a (d, b) (d, c) (***) :: a b c -> a b' c' -> a (b, b') (c, c') (&&&) :: a b c -> a b c' -> a b (c, c') -- Defined in Control.Arrow instance Arrow (->) -- Defined in Control.Arrow instance (Monad m) => Arrow (Kleisli m) -- Defined in Control.Arrow Prelude Control.Arrow> Leaving GHCi. I can't build[2] arrows-0.3 package without `>>>' in Arrow. 2. vvv@fun:~/src/arrows$ darcs w { hunk ./Control/Arrow/Operations.hs 36 +import Control.Category ((>>>)) hunk ./Control/Arrow/Transformer/CoState.hs 23 +import Control.Category ((>>>)) } vvv@fun:~/src/arrows$ runhaskell Setup build Preprocessing library arrows-0.3... Building arrows-0.3... [ 3 of 12] Compiling Control.Arrow.Transformer.CoState ( Control/Arrow/Transformer/CoState.hs, dist/build/Control/Arrow/Transformer/CoState.o ) Control/Arrow/Transformer/CoState.hs:29:7: `>>>' is not a (visible) method of class `Arrow' The question arises "should I?", but this is one of lambdabot's[3] depencies. 3. http://code.haskell.org/lambdabot/ Thanks a lot! -- vvv

3 3

tools for comparing ghc's debug outputs?
by Claus Reinke 31 Jul '08

31 Jul '08

What tools are there for facilitating comparisons of ghc's debug output? I have reduced a performance problem in my code to a case where switching two lines of code doubles or halves the performance (the results of those lines are stored in record fields that never get used in this reduced example.., see ghc trac ticket #2463). So it should be easy to take the outputs of -ddump-simpl, etc. for both variants and run them through a diff viewer, but there are way too many irrelevant differences and details. I seem to recall someone mentioning a tool for normalizing the output of things like -ddump-simpl to make diffs easier by reducing irrelevant differences due to gensym-generated names. Was that just wishful thinking, or does such a thing exist?-) Also, it might be useful if one could translate the transformed code back to highlevel (ghc-)Haskell that would generate the same low-level code (ie, pretending that the source-to-source transformations actually happened at source level). Not only would that blend out irrelevant details, it would also give a direct indication of how to modify the source to get better performing code. What tools are there, and which do you use/recommend for tasks like this? Thanks, Claus

3 3

Build system woes
by Roman Leschinskiy 30 Jul '08

30 Jul '08

Hi all, SimonPJ asked me to summarise the problems I've been having with GHC's new build system with the idea that we could perhaps talk a bit about this during today's IRC meeting. The context is the Data Parallel Haskell project and in particular the dph packages which need a number of not quite straightforward things from the build system (this is only going to get worse in the future). A lot of the problems stem from Cabal's lack of extensibility. This means that whenever I need some new Cabal functionality for dph I have to ask Ian or Duncan to implement it. They both are very helpful but this just doesn't scale! IMO, at the moment Cabal is simply not mature enough for building complex projects. But wait, we do have those Setup.hs files which are customisable so why don't I just do what I want with them? Firstly, they aren't customisable enough. And secondly, I have no idea how to do what I want. The development version of Cabal changes on a daily basis and isn't documented. For instance, the black magic that Ian implemented in dph/dph/Setup.hs a month ago (and which I don't really understand) has been broken once already. Fortunately, I was able to fix that myself but if something more complex changes, I'll have to ask Ian again. In effect, I'm not able to properly maintain my own library! I don't think I understand how GHC itself is built any longer, either. What does cabal-bin do? What is runghc.wrapper? What is the difference between make.library.* and build.library.* and why do we need both (and why doesn't one of them work for dph)? It is important to have an idea how the build system works when hacking on a project but how do I find out? And finally, there is the problem of the HEAD being broken quite frequently. I have decided to pull as little as possible and it turns out that others have independently arrived at the same conclusion. This is bad! For instance, I would have spotted the OS X breakage much earlier if I pulled more frequently; now, I have to wade through a couple of weeks' worth of patches to find the culprit (that darcs unpull doesn't work in my repo doesn't help). IMO, the main issue is that we have two moving targets: the GHC build system and the tool it relies on (Cabal). Both change rapidly and there is just no chance, for me at least, to keep up. If I understand correctly, the situation is this: - Ultimately, Cabal will be used for building GHC. - At the moment, Cabal doesn't provide the necessary functionality. The current approach seems to be to gradually implement stuff in Cabal and to immediately use it in the build system. I think this just doesn't work for a highly collaborative project such as GHC. I have two suggestions how to improve things. 1. I think it would be better to implement, document and release all the necessary functionality in Cabal first and only then to modify GHC's build system to use this functionality. In effect, this means that the Cabal version used for building GHC would be frozen at the beginning of a development cycle and not at the end. Critical stuff could still be merged, perhaps, but that should happen very infrequently and be backwards compatible. 2. Ian, it would be great if you could add a couple of lines to build system patches explaining what they do and why. This could ultimately mean less work for you because I will bug you less often :-) Sorry for the long rant, I simply seem to spend too much time wrestling with the build system. Roman

6 6

Weekly IRC meeting?
by Simon Marlow 30 Jul '08

30 Jul '08

Hi folks, I've been wondering whether it would be useful to have a weekly IRC meeting to discuss GHC. The idea would be that this is a scheduled time when the developers turn up on #ghc, we'll discuss current topics around GHC, and users can chime in with questions, points for discussion, complaints :-) and so on. I imagine making it completely informal to begin with, and later adding some structure (an agenda etc.) if necessary. Another option is a conference call, but personally I prefer the IRC medium for this kind of meeting. A conference call could work too, though. Thoughts? I'm thinking a time around 1600 UK time (currently UTC+1) would probably work best, does anyone have preferences for days? Cheers, Simon

12 21

ghci and source files
by Johannes Waldmann 30 Jul '08

30 Jul '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear all, how does ghci (actually, the ghc API functions) access the file system? (It needs to check whether source files had been updated.) Is it possible to insert an abstraction layer there? E.g. imagine the sources are not on the file system, but in Eclipse edit buffers. - Any hints appreciated. J.W. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEUEARECAAYFAkiPJUEACgkQDqiTJ5Q4dm99LQCXcaCtKnvEsmoGdJ+UQ93A2x0Z 2ACbBfaSZsvU0xHeh/jQbZZjI5VAEdQ= =eQ4p -----END PGP SIGNATURE-----

3 4

Retainer profiling -- too slow?
by Tim Chevalier 30 Jul '08

30 Jul '08

Hi all, Are there any known problems with retainer profiling in GHC 6.8.2? I have a program that takes 3 minutes to run with "normal" profiling enabled (+RTS -P -RTS), but with +RTS -P -hr -RTS, it's 20 minutes and counting. I can tell that progress is being made since the .hp file keeps getting bigger, but that seems like a lot of overhead. I can try to come up with a smaller test case if necessary; just wanted to see if there's any known problem. Cheers, Tim -- Tim Chevalier * http://cs.pdx.edu/~tjc * Often in error, never in doubt "The trouble with academia is that there's a lot of 'If you'll validate my program of Kumquat Studies I won't point out the uselessness of your doctorate in Nail File Studies.'" -- Sarah Barton

2 1

GHC 6.8.3 in Debian?
by Peter Gammie 29 Jul '08

29 Jul '08

Ian - how long until GHC 6.8.3 makes it into Debian's unstable repository? (Just curious how long it takes, and flying the flag of interest.) BTW is there another .deb repository out there for bleeding-edge Haskell artefacts? I believe there used to be, but the URLs in those old (2004) emails seem dead now. cheers peter -- http://peteg.org/

2 1