October 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

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

Control.Exception
by Johannes Waldmann 05 Nov '08

05 Nov '08

with 6.10, the following does not typecheck: foo `Control.Exception.catch` \ _ -> return bar Ambiguous type variable `e' in the constraint: `Control.Exception.Exception e' It is probably bad programming style anyway but what is the workaround? I found some references (in list emails) to catchAny, ignoreExceptions but these don't seem to have made it? Best regards, J.W.

9 17

ANNOUNCE: GHC 6.10.1 RC 1
by Ian Lynagh 03 Nov '08

03 Nov '08

We are pleased to announce that the GHC 6.10.0.20081007 snapshot is the first release candidate for GHC 6.10.1. You can download the release candidate from here: http://www.haskell.org/ghc/dist/stable/dist/6.10.1-rc-1/rc.html This page includes: * a Windows installer * an OS X installer * bindists for amd64/Linux and ix86/Linux * the sources There is also a status page here: http://hackage.haskell.org/trac/ghc/wiki/GHC-6.10.1 where we will keep track of where the RC works, and where it is known to have problems. This is a wiki page, so please feel free to update it if you are able to add or update the information on a particular platform. Please test as much as possible; bugs are much cheaper if we find them before the release! We hope that we will be able to make the final release in around one weeks time, but of course that may slip if problems are uncovered. Thanks Ian, on behalf of the GHC team

8 15

Dilemma: DiffArray non-performance vs STArray non-readability
by Claus Reinke 03 Nov '08

03 Nov '08

I keep wanting to use DiffArray as the natural functional solution to single-threaded array use. But everytime I try, I get smacked over the head with the actual performance figures. Sometimes, even plain arrays are faster in a loop doing array updates, in spite of all the copying involved. And when copying on update dominates the runtime, using IntMap tends to be faster - the "indirections" are the wrong way round, but don't pile up, just that array lookups aren't quite constant time. But when I really need to avoid the updates, and need constant time lookup, I'm stuck: DiffArray tends to slow everything down (I vaguely recall locks and threads being at the heart of this, but I haven't checked the code recently), so my only option seems to be to transform my nice functional code into not-nice sequential code and use STArray. Is there any way out of this dilemma? What do other Ghc users use? If locks really are the issue, perhaps using STM instead of MVars in the DiffArray implementation could help. As long as my array uses are single-threaded, STM optimism might be able to avoid waiting/scheduler issues? Or am I on the wrong track? Claus PS Btw, I thought the DiffArray performance issue was ancient, but I can't find a ticket for it, nor does the haddock page for Data.Array.Diff mention this little hickup. Should I add a ticket?

4 4

cabal
by Christian Maeder 01 Nov '08

01 Nov '08

Hi, currently I've got a problem installing from hackage. using: GHC (package manager) version 6.10.0.20081019 cabal-install version 0.6.0 using version 1.6.0.1 of the Cabal library I get: Building network-2.2.0.0... Network/URI.hs:128:7: Could not find module `Data.Generics': it is a member of package base-3.0.3.0, which is hidden even with: cabal install network --constrain="base<4" (A similar problem happened with Shellac.) How is the smart selection between base-3 and base-4 going to work? Eventually, I want to install hxt-filter and Shellac-compatline. (The interface in editline changed for Shellac-editline.) Cheers Christian

4 6

file descriptors
by Johannes Waldmann 30 Oct '08

30 Oct '08

Dear all, are there any known issues with file handles/descriptors in ghc-compiled executables? My program has a lot of calls to System.Process.runInteractiveProcess and I'm running into unpredictable behaviour (sometimes the program just silently dies, sometimes it gets stuck) The handles I get correspond to file descriptors in the OS? Could there be any conflicts? (Like not enough available, or re-used to early etc.) Or perhaps you see anything that's wrong with my code here http://dfa.imn.htwk-leipzig.de/cgi-bin/cvsweb/box/src/SMT/Time.hs?rev=1.9 I'm compiling this with -threaded, but running with -N1. Of course, terminateProcess is another source of uncertainty here. (Sometimes it takes several seconds until the external process dies.) Any hints appreciated. - J.W.

3 2

gadt changes in ghc 6.10
by Daniel Gorín 30 Oct '08

30 Oct '08

Hi After installing ghc 6.10-rc, I have a program that no longer compiles. I get the dreaded "GADT pattern match...." error, instead :) Here is a boiled-down example: {-# OPTIONS_GHC -XGADTs -XEmptyDataDecls #-} module T where data S data M data Wit t where S :: Wit S M :: Wit M data Impl t a where I1 :: Maybe a -> Impl S a I2 :: [a] -> Impl M a type W_ t a = Wit t -> Impl t a newtype W t a = Wrap (W_ t a) bind :: W t a -> (a -> W t b) -> W_ t b bind (Wrap w) f = \wit -> case wit of S -> case w S of I1 m -> I1 $ do a <- m case f a of Wrap w' -> case w' S of I1 m' -> m' M -> case w M of I2 m -> I2 $ do a <- m case f a of Wrap w' -> case w' M of I2 m' -> m' While in ghc 6.8.3 this compiles fine, with ghc 6.10 i get: $ ghc --make T.hs [1 of 1] Compiling T ( T.hs, T.o ) T.hs:26:57: GADT pattern match with non-rigid result type `Maybe a' Solution: add a type signature In a case alternative: I1 m' -> m' In the expression: case w' S of { I1 m' -> m' } In a case alternative: Wrap w' -> case w' S of { I1 m' -> m' } I've tried adding some signatures (together with - XScopedTypeVariables), but with no luck. Why is it that this no longer compiles? More importantly, how can I make it compile again? :) Thanks! Daniel

4 8