September 2010 - 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

Non-exhaustive pattern match(es) warning in lambda functions
by Mitar 18 Nov '10

18 Nov '10

Hi! Why GHC does not warn (with -Wall) about non-exhaustive pattern match(es) warning in lambda functions? For example, this code: data Foo = Bar | Baz test1 :: Foo -> IO () test1 Bar = return () -- Pattern match(es) are non-exhaustive warning, OK test2 :: Foo -> IO () test2 = \Bar -> return () -- No pattern match(es) are non-exhaustive, BAD I think it would be quite useful to also catch such situations and issue a warning. Mitar

4 9

ANNOUNCE: GHC 7.0.1 Release Candidate 1
by Ian Lynagh 25 Oct '10

25 Oct '10

We are pleased to announce the first release candidate for GHC 7.0.1: http://new-www.haskell.org/ghc/dist/7.0.1-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux and i386/Linux. Please test as much as possible; bugs are much cheaper if we find them before the release! Thanks Ian, on behalf of the GHC team

15 43

Re: clearing GHCi (and, by extension, hint) loaded module dependencies
by Alex Suraci 24 Oct '10

24 Oct '10

On Tue, Sep 21, 2010 at 10:30 AM, Daniel Gorín <jcpetruzza(a)gmail.com> wrote: > Hi > > What I make of this is that you should run a new interpreter (i.e. use runInterpreter(T)) instead of calling reset. > > Could you try this this approach and see if it works? > > Daniel Every "load:" call already runs its own interpreter. I guess the session is sticking around somewhere in-between. I've been playing around with hint and the GHC API trying to figure this one out (with Simon's tips in mind), but haven't found a way to discard the session, or even on what level that should be done. In runInterpreter? Or in separate runGhc calls? The best guess I have so far is using getSession/setSession inside the interpreter call to restore it to the way it was before, but that seems to have no effect. Here's what I'm using to test: http://hpaste.org/40015/hintghc_memory Even with setSession, the cache seems to be sticking around - subsequent loads are faster, and the memory usage doesn't go down. -- Alex

3 7

Re: ANNOUNCE: GHC 7.0.1 Release Candidate 1
by Vivian McPhail 17 Oct '10

17 Oct '10

Trying to build rc1 from source linux x86_64 BuildFlavour = perf It seems that the -fPIC flag is set, but an error still occurs ( /usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC ) "inplace/bin/ghc-stage1" -fPIC -dynamic -O -H64m -package-name base-4.3.0.0 -hide-all-packages -i -ilibraries/base/. -ilibraries/base/dist-install/build -ilibraries/base/dist-install/build/autogen -Ilibraries/base/dist-install/build -Ilibraries/base/dist-install/build/autogen -Ilibraries/base/include -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include -optPlibraries/base/dist-install/build/autogen/cabal_macros.h -package ghc-prim-0.2.0.0 -package integer-gmp-0.2.0.2 -package rts-1.0 -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XNoImplicitPrelude -XCPP -no-user-package-conf -rtsopts -O2 -XGenerics -fno-warn-deprecated-flags -odir libraries/base/dist-install/build -hidir libraries/base/dist-install/build -stubdir libraries/base/dist-install/build -hisuf dyn_hi -osuf dyn_o -hcsuf dyn_hc -c libraries/base/./Data/Typeable.hs-boot -o libraries/base/dist-install/build/Data/Typeable.dyn_o-boot /usr/bin/ld: libraries/integer-gmp/gmp/objs/abs.o: relocation R_X86_64_32 against `.text' can not be used when making a shared object; recompile with -fPIC libraries/integer-gmp/gmp/objs/abs.o: could not read symbols: Bad value collect2: ld returned 1 exit status make[1]: *** [libraries/integer-gmp/dist-install/build/ libHSinteger-gmp-0.2.0.2-ghc7.0.0.20100924.so] Error 1 make[1]: *** Waiting for unfinished jobs.... make: *** [all] Error 2 Vivian

5 4

haddock and associated data families
by Christian Höner zu Siederdissen 04 Oct '10

04 Oct '10

Hi, haddock seems to produce an error on associated data family decls.: http://hackage.haskell.org/packages/archive/PrimitiveArray/0.0.2.1/logs/fai… line 22, where the errors occurs is exactly this one: class PrimArrayOps a b where data PrimArray a b :: * -- ^ PrimArray data type I'll fix it by trying other methods to put comments there. Could someone enter this as a bug, if it is not done yet? (Assuming it is a bug ;-) Thanks, Christian

3 2

Parallel build broken
by Florian Weimer 01 Oct '10

01 Oct '10

<http://hackage.haskell.org/trac/ghc/wiki/Building/Hacking> says that parallel builds are supported, but this doesn't seem to be true anymore. This is a bit unfortunate because in theory, builds should parallelize quite well.

2 2

GHC 7.0.1 rc1: Could not deduce (Typeable a) from the context (Typeable a, …)
by Malte Sommerkorn 01 Oct '10

01 Oct '10

While compile failures were easy to fix for syb, X11 and xmonad, here's a more mysterious encounter with xmonad-contrib. The module in question is http://code.haskell.org/XMonadContrib/XMonad/Layout/MultiToggle.hs and the rest of this mail is the error: XMonad/Layout/MultiToggle.hs:194:30: Could not deduce (Typeable a) from the context (Typeable a, Show ts, HList ts a, LayoutClass l a) arising from a use of `fromMessage' Possible fix: add (Typeable a) to the context of the instance declaration In a stmt of a pattern guard for an equation for `handleMessage': Just (Toggle t) <- fromMessage m In an equation for `handleMessage': handleMessage mt m | Just (Toggle t) <- fromMessage m, i@(Just _) <- find (transformers mt) t = case currLayout mt of { EL l det -> do { l' <- fromMaybe l `fmap` handleMessage l (SomeMessage ReleaseResources); .... } where cur = (i == currIndex mt) } | otherwise = case currLayout mt of { EL l det -> fmap (fmap (\ x -> mt {currLayout = EL x det})) $ handleMessage l m } In the instance declaration for `LayoutClass (MultiToggle ts l) a' XMonad/Layout/MultiToggle.hs:195:25: Could not deduce (HList ts a) from the context (Typeable a, Show ts, HList ts a, LayoutClass l a, Transformer t a) arising from a use of `find' Possible fix: add (HList ts a) to the context of the data constructor `Toggle' or the instance declaration In a stmt of a pattern guard for an equation for `handleMessage': i@(Just _) <- find (transformers mt) t In a stmt of a pattern guard for an equation for `handleMessage': Just (Toggle t) <- fromMessage m In an equation for `handleMessage': handleMessage mt m | Just (Toggle t) <- fromMessage m, i@(Just _) <- find (transformers mt) t = case currLayout mt of { EL l det -> do { l' <- fromMaybe l `fmap` handleMessage l (SomeMessage ReleaseResources); .... } where cur = (i == currIndex mt) } | otherwise = case currLayout mt of { EL l det -> fmap (fmap (\ x -> mt {currLayout = EL x det})) $ handleMessage l m }

2 3

report on 7.01-pre
by Serge D. Mechveliani 30 Sep '10

30 Sep '10

Dear GHC developers, http://botik.ru/pub/local/Mechveliani/ghcBugs/ghc701preBug.zip contains a bug report on ghc-7.0.0.20100924 tested on Debian Linux, i386-family. Its essence is as follows. At the fragment of --------------------------------------------------------------------- instance (LinSolvRing (Pol a), CommutativeRing a) => -- (1) LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP = f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... --------------------------------------------------------------------- in the module Pol3_.hs, ghc-7.0.0.20100924 reports that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. ghc-6.12.2 compiles this in a correct way: (EuclideanRing a) is not necessary here, while the context (1) is more generic and sufficient. For example, for a = DirectSum Integer Integer, `a' has the instances (1) and has not the instance of Euclidean, and the above code must work. This is the idea of the author of the application; this idea is supported by ghc-6.12.2 and not supported by ghc-7.0.0.20100924. There are the two questions. 1) Whether this intention with instances is correct in the meaning of Haskell + ghcExt (I hope, it is correct, at least, ghc-6.12.2 accepts it). 2) If it is correct, why ghc-7.0.0.20100924 requires (Euclidean a) ? Notices ------- a) This application uses multiparametric classes and overlapping instances (see docon.cabal for language and other options). b) The example code can be reduced further, many times. But I may have time to reduce it maybe only in the middle of December 2010. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

testing 7.01-pre
by Serge D. Mechveliani 30 Sep '10

30 Sep '10

Dear GHC developers, I have tested ghc-7.0.0.20100924 on Debian Linux, i386-family on making it by ghc-6.12.3, on the DoCon test, -- with skipping profiling. There are visible the following changes in GHC: (1) Usage of ./Main +RTS .. -RTS needs linking with -rtsopts (2) ghc-6.12.2 compiles docon-2.11 (download it via http://haskell.org/ghc/docon/ and follow install.txt ) and ghc-7.0.0.20100924 cannot. It declares ... DPair.hs:316:35: Couldn't match type `b' with `a' `b' is a rigid type variable bound by the instance declaration at DPair.hs:222:38 `a' is a rigid type variable bound by the instance declaration at DPair.hs:222:23 In the first argument of `restore', namely `zrB' In the expression: restore zrB bs qB' In an equation for `qB': qB = restore zrB bs qB' (3) I also tried docon-2.12 (which differs very slightly from docon-2.11 and which I can provide if asked). ghc-6.12.3 makes it and runs the test successfully. Compiling it by ghc-7.0.0.20100924 stops (close to end) at Pol3_.hs at the fragment of --------------------------------------------------------------------- instance (LinSolvRing (Pol a), CommutativeRing a) => LinSolvRing (UPol (Pol a)) where gxBasis [] = ([], []) gxBasis fs@(f:_) = let UPol _ p y dP = f (o, n) = (pPPO p, genericLength $ pVars p) (toLex, fromLex) = (reordPol $ lexPPO n, reordPol o) p' = toLex p dP' = upLinSolvRing p' Map.empty s' = cToUPol y dP' p' ... ---------------------------------------------------------------- It declares that the line of `s' =' needs (EuclideanRing a) and that it cannot deduce it. I think, for the need of this particular application it is indeed better to change the context to `EuclideanRing a =>' (probably, the initial complicated context was forced by old GHC). After changing it to `EuclideanRing a =>', ghc-7.0.0.20100924 makes docon-2.12 and runs the test successfully. You see, the points (2) and (3) present a certain question about the compler. I wonder wich complier is more correct. (Recall also that Docon uses an extension with overlapping instances, multiparametric classes, and such). (4) At the docon-2.12 test made under -O, ghc-7.0.0.20100924 shows the time 3.9 sec instead of 3.3 sec of ghc-6.12.3. Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

2 2