October 2012 - Glasgow-haskell-users

GHC build linking error
by wren ng thornton 29 Nov '12

29 Nov '12

Hello all, I'm working on creating some distribution bundles of GHC 7.4.1 and HP 2012.2.0.0 for OSX 10.5 to help rectify the lack of support on older Macs. In building GHC I've run into a linking error in stage1: ld: duplicate symbol ___gmpz_abs in libraries/integer-gmp/gmp/objs/add.o and libraries/integer-gmp/gmp/objs/abs.o Which looks like the same issue discussed in: http://www.haskell.org/pipermail/glasgow-haskell-users/2011-December/021339… The only proposed solution was Sean mentioned explicitly passing the GMP.framework to ./configure via --with-gmp-libraries and --with-gmp-includes; however, I have no such GMP.framework (I'm building from the framework versions of GHC 6.12.1 and HP 2010.1.0.0). So, any ideas on how to fix this? -- Live well, ~wren

3 3

Executables got bigger using dynamic link.
by Magicloud Magiclouds 26 Nov '12

26 Nov '12

Hi, I set "shared: True" in ~/.cabal/config, and using ghc 7.6.1. Then clear user space hackages and reinstall them. First of all, I think comparing to static link, dynamic linked executables file should be smaller. And the libraries (.so) could benefits from caching to save memory usage. Well, I installed cabal-install and alex. I got this: cabal 9.9M -> 24M alex 2.7M -> 5.1M Is this correct? -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

2 2

TypeHoles: unbound variables as named holes
by Sean Leather 21 Nov '12

21 Nov '12

(I'm again starting a new thread to focus on this issue. It's easier to track that way.) On Thu, Oct 4, 2012 at 11:40 AM, Simon Peyton-Jones wrote: > There is also the small matter, in this example, of distinguishing which > `_' is which. The description works, but you have to think about it. I > don't have an immediate and simple solution to this. Perhaps the addition > of unique labels (e.g. _$1 _$2). But this is not a major problem. It can > even wait until some future development/expansion on TypeHoles. > Just to clarify the "small matter" above, I was proposing a way to reference unnamed holes in the warning messages. This was only to solve the relatively minor problem of visually distinguishing the holes if there are multiple. **** > > I have a proposal. Someone has already suggested on > hackage.haskell.org/trac/ghc/ticket/5910 that an un-bound variable > behaves like a hole. Thus, if you say > > ** ** > > f x = y**** > > GHC says “Error: y is not in scope”. But (idea) with -XTypeHoles**** > > ** ** > > f x = y**** > > might generate **** > > **1. **(renamer) *Warning*: y is not in scope**** > > **2. **(type) *Error*: Hole “y” has type....**** > > So that’s like a named hole, in effect. **** > > ** ** > > If you say**** > > f x = 4**** > > GHC warns about the unused binding for x. But if you say**** > > f _x = 4**** > > the unused-binding warning is suppressed. So (idea) if you say**** > > f x = _y**** > > maybe we can suppress warning (1). And, voila, named holes.**** > > ** ** > > Moreover if you add –fdefer-type-errors you can keep going and run the > program.**** > > ** ** > > Any comments? This is pretty easy to do. > I also like the proposal; however, I think it only makes sense if the set of unbound variables with the same name is treated as referring to the same identifier. This was, after all, the main reason for named holes. Roman expected this, and I think everybody who uses the feature will expect it. On Fri, Oct 5, 2012 at 9:24 AM, Roman Cheplyaka wrote: > * Roman Cheplyaka [2012-10-05 10:22:23+0300] > > * Simon Peyton-Jones [2012-10-05 07:14:36+0000] > > > | Sounds cool. I would also expect that if you have several occurences > of > > > | the same unbound identifier, then it gets a unified type. > > > > > > I thought about this, but I think not. Consider > > > > > > f x1 = _y > > > g x2 = _y > > > > > > Do you want _y and _y to be unified, so that f and g are no longer > polymorphic? I think not. Any more than the "_" holes we have now are > unified. > > > > Do you mean polymorphism in their argument? Why would it go away? > > > > I would expect the functions to get types `a -> c` and `b -> c` > > respectively, and `c` to be reported as the type of the hole. > > Ah, I see. Since `c` is universally quantified, it means different > things for f and g. Good point. > I would expect `_y' to be unified. I'm not sure how to write the type of `f' or `g' (maybe `forall a. a -> c' and `forall b. b -> c'?), but I would still expect `_y' to have some type `c'. It would be endlessly confusing to have identifiers that look the same but aren't. Here's a thought that just occurred to me, though I'm not yet sure if it makes sense. Treat all expression identifiers _x as unique but report them as one hole with all possible types. Then, you can visually identify the patterns between the types. So: > f x = _y > g x = _y 'a' with some warning like this: Found hole `_y' in multiple locations with the possible types File.hs:##:##: a0 File.hs:##:##: Char -> b0 Now, I know by looking at it that `a0' and `b0' are universally quantified per location, but I can do some mental unification myself. Regards, Sean >

4 4

Kind refinement in type families with PolyKinds
by José Pedro Magalhães 31 Oct '12

31 Oct '12

Hi all, I'm wondering why the following does not work: {-# LANGUAGE DataKinds #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE KindSignatures #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeOperators #-} > > module Bug where > > -- Type equality > data a :=: b where Refl :: a :=: a > > -- Applying a type to a list of arguments > type family Apply (t :: k) (ts :: [*]) :: * > type instance Apply t '[] = t > type instance Apply (f :: * -> *) (t ': ts) = f t > > -- Stripping a type from all its arguments > type family Strip (t :: *) :: k > type instance Strip (Maybe a) = Maybe > > -- Reapplying a stripped type is the identity > x :: Apply (Strip (Maybe a)) (a ': '[]) :=: Maybe a > x = Refl > If I ask GHCi for the kind of `Strip (Maybe Int)`, I get `k`, whereas I would expect `* -> *`. That explains why the `Apply` type family is not reduced further. I understand that this might be related to GADTs not being allowed to refine kinds; the following datatype fails to compile with the error "`D1' cannot be GADT-like in its *kind* arguments": data DStrip :: k -> * where > D1 :: DStrip Maybe > But then, shouldn't the type instance for `Strip` above trigger the same error? Thanks, Pedro

4 4

Why are arrays retainers?
by Akio Takano 30 Oct '12

30 Oct '12

Hi, Recently I was surprised to see that GHC's retainer profiler treated boxed arrays as retainer objects. Why are they considered retainers? I was using the +RTS -hr to figure out why there were a lot of objects of type T in the heap. However, the T objects happened to be in a HashMap (from the unordered-containers package), so the profiler pointed to the function that created the HashMap rather than the actual cause of the leak. This lead me to think that it might be useful if GHC would treat arrays as non-retainers. Also the behavior is not documented. The user's guide only mentions stacks and thunks as types of retainers, not mutable objects and boxed arrays. I'd be happy to submit a documentation patch. Regards, Takano Akio

2 2

Using GHC.TypeLits and singletons
by José Pedro Magalhães 29 Oct '12

29 Oct '12

Hi Iavor and Richard (CC ghc-users), If I recall correctly, Richard designed his singletons package in such a way that it would interact nicely with Iavor's type-level literals. Now I find myself in a situation where I need to use both type-level literals and singletons (basically because I'm reflecting at the value level both naturals, strings, and more complicated datatypes). But I see that the declarations of entities such as Sing, SingI, etc., are duplicated in the singletons package (seeing that they are already in GHC 7.6 within GHC.TypeLits). My question is: how can I use these two together? Thanks, Pedro

2 1

Understanding the core2core simplifier <-> occurence-analysis interaction
by Herbert Valerio Riedel 28 Oct '12

28 Oct '12

Hello GHC HQ, I've been trying to improve/fix a minor optimization sub-optimality w.r.t to the following code (code like that results from the generics-based NFData deriver[1]): data Foo = Foo1 | Foo2 | Foo3 !Int rnf1 :: Foo -> () rnf1 x = case x of Foo1 -> () Foo2 -> () Foo3 {} -> () which the current GHC 7.6.1 translates to the following core expression: NFDataTest2.rnf1 = \ x_aeG -> case x_aeG of _ { __DEFAULT -> GHC.Tuple.(); NFDataTest2.Foo3 ds_deT -> GHC.Tuple.() } ...whereas I'd have expected it to to compile it to a collapsed '__DEFAULT'-only case, i.e. NFDataTest2.rnf1 = \ x_aeG -> case x_aeG of _ { __DEFAULT -> GHC.Tuple.() } Now I've been hunting it down to the function SimplUtils.mkCase1 [2], which according to the source-code comments, is supposed to merge identical alternatives, i.e.: | 3. Merge identical alternatives. | If several alternatives are identical, merge them into | a single DEFAULT alternative. I've occasionally seen this | making a big difference: | | case e of =====> case e of | C _ -> f x D v -> ....v.... | D v -> ....v.... DEFAULT -> f x | DEFAULT -> f x ...and the 'mkCase1' function itself reads as follows: mkCase1 dflags scrut case_bndr alts_ty ((_con1,bndrs1,rhs1) : con_alts) | all isDeadBinder bndrs1 -- Remember the default , length filtered_alts < length con_alts -- alternative comes first -- Also Note [Dead binders] = do { tick (AltMerge case_bndr) ; mkCase2 dflags scrut case_bndr alts_ty alts' } where alts' = (DEFAULT, [], rhs1) : filtered_alts filtered_alts = filter keep con_alts keep (_con,bndrs,rhs) = not (all isDeadBinder bndrs && rhs `cheapEqExpr` rhs1) ...now the problem seems to be, that 'isDeadBinder' returns 'False'; so I hacked up 'mkCase1' and inserted a 'occurAnalyseExpr' on artificially constructed single-alternative 'Case' values before applying 'isDeadBinder', and then it would return 'True' and simplify the case expression as expected. So now my question is, why isn't the occurrence information available for the case-alternative's binders (the occInfo is set to 'NoOccInfo') at 'mkCase1'-time? When is occurence analysis performed relative to the simplifier? [1]: http://hackage.haskell.org/package/deepseq-generics [2]: http://www.haskell.org/ghc/docs/7.6.1/html/libraries/ghc-7.6.1/src/SimplUti… cheers, hvr --

1 1

GHC on OpenIndiana
by asyropoulos＠aol.com 28 Oct '12

28 Oct '12

Dear Developers, I am trying to compile the GHC on OpenIndiana (essentially Solaris 11). I follow the steps in http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html#se… and here is what I get: $ ./distrib/hc-build --prefix=/opt/gnu/ghcb --enable-hc-boot *** Building compiler... checking for gfind... /usr/bin/gfind checking for sort... /opt/gnu/bin/sort checking for ghc... no checking build system type... i386-pc-solaris2.11 checking host system type... i386-pc-solaris2.11 checking target system type... i386-pc-solaris2.11 HOST: i386-pc-solaris2.11 Can't work out build platform Not e that configure.ac contains a section on Solaris: SOLARIS_BROKEN_SHLD=NO case $host in i386-*-solaris2) # here we go with the test MINOR=`uname -r|cut -d '.' -f 2-` if test "$MINOR" -lt "11"; then SOLARIS_BROKEN_SHLD=YES fi ;; esac For whatever the reason I "need to update configure.in to recognise the new architecture, and re-generate configure with autoreconf" but I have no idea what exactly to add. There is no template inside to help me. Could you please let me know what should I do to proceed? Thank you in advance for your help/suggestions. A.S. -- Apostolos Syropoulos Xanthi, Greece

3 2

RULES for ByteString are not fired
by Kazu Yamamoto 28 Oct '12

28 Oct '12

Hello, I seems to us (my friends and me) that term rewriting rules for ByteString are not fired in recent GHCs. 6.12.3 OK 7.0.4 NG 7.4.1 NG 7.6.1RC1 NG For example, with the example from this ticket http://hackage.haskell.org/trac/ghc/ticket/3703 results in as follows: % ghc -O -ddump-simpl-stats --make breakOn.hs 14 RuleFired 4 Class op showsPrec 2 Class op show 2 eqChar#->case 2 unpack 2 unpack-list 1 Class op == 1 Class op >> There is no ByteString rules. Is this a bug or intention? --Kazu {-# LANGUAGE OverloadedStrings #-} import qualified Data.ByteString.Char8 as B main :: IO () main = do let string1 = B.pack "This is a string" string2 = B.pack "This is another string" print (breakOn ' ' string1) print (breakOn ' ' string2) breakOn :: Char -> B.ByteString -> (B.ByteString, B.ByteString) breakOn c = B.break (c==)

3 2

ghc: panic! (the 'impossible' happened)
by José Romildo Malaquias 28 Oct '12

28 Oct '12

Hello. Today I wrote a small program to experiment with the Applicative class. The program is supposed to use an "applicative reader", similar to a "monad reader", to evaluate arithmetic expressions. But when compiling the program with ghc-7.6.1, I get the following message: $ ghc --make applicative-eval [1 of 1] Compiling Main ( applicative-eval.hs, applicative-eval.o ) ghc: panic! (the 'impossible' happened) (GHC version 7.6.1 for x86_64-unknown-linux): expectJust cpeBody:collect_args Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug If the line eval (Let s a b) = \m -> eval b ((s,eval a m):m) is commented out, the program compiles without problems. Is this a known issue with the compiler? The source code is attached. Romildo

3 3