November 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

Build system idea
by Simon Marlow 10 Jan '09

10 Jan '09

Simon PJ and I had a talk about the build system earlier today, I thought I'd float the idea we discussed (I should admit that the idea was mine, lest Simon PJ think I'm attributing bad ideas to him :-). This is not completely thought through, but I'm pretty sure a solution exists along these lines that would improve things for us. Ok, the starting point is this: - Cabal has code to generate Makefiles. Almost nobody uses it except for the GHC build system. It essentially duplicates the build system for compiling Haskell source (but not for installation, haddocking, registration, configuration, etc.) - Cabal is a library I propose we do this: - Extract the code from Cabal that generates Makefiles, and treat it as part of the GHC build system. Rather than generating a Makefile complete with build rules, we generate a Makefile that just has the package-specific metadata (list of modules, etc.), and put the code to actually build the package in the GHC build system. This means we still get to use 'make', we still get to use the .cabal files as metadata, but the build system is more private to GHC, more extensible, and hopefully more understandable and modifiable. We can express dependencies that Cabal currently doesn't know about. It would let us avoid the current uncomfortable situation where we have to feed all kinds of configuration information from the GHC build system into Cabal - Cabal would be essentially just a mechanism for translating the .cabal file into Makefile bindings and package metadata for ghc-pkg. There will undoubtedly be some sticking points where we have to tradeoff duplicating things from Cabal against re-using parts of Cabal which might require modifying Cabal itself. For instance, we could use Cabal for installation, but that means that our build system has to leave everything in the places that Cabal's installation code expects, so it might be more feasible to do installation ourselves, but that means duplicating parts of Cabal. It will probably mean that we have a tighter dependency on Cabal, because we use it as a library rather than a black box; but hopefully we can keep our branch of Cabal more stable and not have to update it so often. Anyway, this is an idea that I think is interesting. Obviously it needs a lot more fleshing out to be a real proposal, but I'm interested in whether anyone thinks this idea is worth persuing, or whether there are better alternatives. Cheers, Simon

16 49

ghc 6.10.1 on freebsd 7 amd64 - ghci problems
by Markus Barenhoff 08 Jan '09

08 Jan '09

Hi! Because the ports seem not to get updated, I tried to compile ghc 6.10.1 under freebsd 7 on amd64 myself. For compiling I first used the ports ghc version (6.8.3) and then, in a second try I used the self build 6.10.1 to build it again. I added building of api docs with: $ echo "HADDOCK_DOCS = YES" >> mk/build.mk I configured it with a simple ./configure and not more options. The compiler seems to work well on both versions. But if i try to start ghci I get the following: ---- snip ---- $ ghci GHCi, version 6.10.1: http://www.haskell.org/ghc/ :? for help ghc: Unable to mmap() for jump islands Loading package ghc-prim ... ghc: panic! (the 'impossible' happened) (GHC version 6.10.1 for x86_64-unknown-freebsd): loadObj: failed Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug ---- snip ---- It looks he has some kind of library loading problems? Any ideas? Thnx and regards Markus

3 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

Can't compile GHC 6.8.2
by Barney Stratford 21 Dec '08

21 Dec '08

I'm trying to compile GHC 6.8.2 using my existing GHC 6.2, but the typechecker refuses to compile. The problem seems to be that the hi-boot files in compiler/typecheck contain some incorrect type signatures. I've fixed most of them, but TcMatches.hi-boot-6 has slightly stumped me. As it stands, it says tcMatchesFun :: Name.Name -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) but it should say something like tcMatchesFun :: Name.Name -> Bool -> HsExpr.MatchGroup Name.Name -> TcType.BoxyRhoType -> TcRnTypes.TcM (HsBinds.HsWrapper, HsExpr.MatchGroup TcRnTypes.TcId) Unfortunately, that doesn't work, as it assumes I meant TcMatches.Bool, so I tried saying Prelude.Bool instead. Now I get the complaint that Prelude.Bool isn't in scope. Has anyone else seen this issue? I've looked for answers in the docs and with Google, but no luck. I'm running Mac OS 10.3, with GHC 6.2 installed under Fink. I borrowed the Fink package for GHC 6.8.2 and adapted it slightly so it would bootstrap from my existing GHC, as the bootstrap code available for download relies on a later version of my OS. GHC 6.2 can't compile GHC 6.10, which is why I'm going for the earlier version. Cheers, Barney.

7 20

GHCi debugger status
by Daniil Elovkov 01 Dec '08

01 Dec '08

Hello folks I'd like to know, how do ghc developers and users feel about the debugger? I'm using it to some extent on ghc 6.8.2 and find it useful. But I'm getting an impression that it's not too stable. I'm not filing any bug report yet, just want to know how it feels for others. I used to make it panic. I think, it was due to existential types. Now I see it mess up the list of bindings in a funny way. For example, in a previous trace session I had a variable, say, prev. It was bound during pattern matching in a function, say, prevFunc. Now I'm having another trace session, actually stepping from the very beginning. A couple of steps after the beginning, prev suddenly appears in the bindings where prevFunc absolutely has not yet been invoked. It's completely unrelated. In 'show bindings' prev has a wrong type - SomeType (it's ADT). Its real type (when in scope) is [t]. I ask 'length prev' and get 0 :) So, what is your impression of the debugger? -- Daniil Elovkov

6 24

cross module optimization issues
by John Lato 28 Nov '08

28 Nov '08

Hello, I have a problem with a package I'm working on, and I don't have any idea how to sort out the current problem. One part of my package is in one monolithic module, without an export list, which works fine. However, when I've started to separate out certain functions into another module, and added an export list to one of the modules, which dramatically decreases performance. The memory behavior (as shown by -hT) is also quite different, with substantial memory usage by "FUN_2_0". Are there any suggestions as to how I could improve this? Thanks, John

6 15

GADT Type Checking GHC 6.10 versus older GHC
by Jason Dagit 28 Nov '08

28 Nov '08

Hello, Here is an example where ghc 6.8.x was fine, but now 6.10 complains. \begin{code} type CommuteFunction = forall x y. (Prim :< Prim) C(x y) -> Perhaps ((Prim :< Prim) C(x y)) commute_split :: CommuteFunction commute_split (Split patches :< patch) = toPerhaps $ do (p1 :< ps) <- cs (patches :< patch) case sort_coalesceFL ps of p :>: NilFL -> return (p1 :< p) ps' -> return (p1 :< Split ps') where cs :: ((FL Prim) :< Prim) C(x y) -> Maybe ((Prim :< (FL Prim)) C(x y)) cs (NilFL :< p1) = return (p1 :< NilFL) cs (p:>:ps :< p1) = do p1' :< p' <- commutex (p :< p1) p1'' :< ps' <- cs (ps :< p1') return (p1'' :< p':>:ps') commute_split _ = Unknown \end{code} Now with ghc 6.10 we get this error: GADT pattern match with non-rigid result type `Maybe a' Solution: add a type signature In a case alternative: p :>: NilFL -> return (p1 :< p) In the expression: case sort_coalesceFL ps of { p :>: NilFL -> return (p1 :< p) ps' -> return (p1 :< Split ps') } In the second argument of `($)', namely `do (p1 :< ps) <- cs (patches :< patch) case sort_coalesceFL ps of { p :>: NilFL -> return (p1 :< p) ps' -> return (p1 :< Split ps') }' You can see more context here: http://darcs.net/src/Darcs/Patch/Prim.lhs around line 472 My understanding was that from 6.6 to 6.8, GADT type checking was refined to fill some gaps in the soundness. Did that happen again between 6.8 and 6.10 or is 6.10 being needlessly strict here? Thanks, Jason

4 14

simple ghci debugger question
by Peter Hercek 27 Nov '08

27 Nov '08

Is there a way to redirect output of a ghci debugger command so that I can process it with a (ghci) script before it is displayed? Peter.

3 2