- Glasgow-haskell-users

Using DeepSeq for exception ordering
by Simon Hengel 13 Nov '12

13 Nov '12

Hi, I'm puzzled whether it is feasible to use existing NFData instances for exception ordering. Here is some code that won't work: return $!! 'a' : throw exceptionA throwIO exceptionB Here GHC makes a non-deterministic choice between exceptionA and exceptionB. The reason is that the standard DeepSeq instances use `seq`, and `seq` does not help with exception ordering**. I tried several things (ghc-7.4.2 with -O2), and the following seems to order the exceptions for this particular case: (evaluate . force) ('a' : throw exceptionA) throwIO exceptionB But I'm a little bit worried that this may not hold in general, e.g. (return $!! 'a' : throw exceptionA) >>= evaluate throwIO exceptionB results in exceptionB. I think my main issue here is that I do not properly understand how seq and seq# (which is used by evaluate) do interact with each other. And how I can reason about code that uses both. The question is really whether it is "somehow" feasible to use existing NFData instances to order exceptions. Or would we need to define a separate type class + instances for that, e.g.: class DeepEvaluate a where deepEvaluate :: a -> IO a deepEvaluate = evaluate instance DeepEvaluate Char where instance DeepEvaluate a => DeepEvaluate [a] where deepEvaluate = mapM deepEvaluate If you have any related ideas or thoughts, I'd love to hear about them. Cheers, Simon ** This is desired behavior, see the discussion at http://hackage.haskell.org/trac/ghc/ticket/5129

6 12

Undocumented(?) magic "this" package-id in PackageImports
by Herbert Valerio Riedel 13 Nov '12

13 Nov '12

Hello Simon, I just found out that in combination with the PackageImports extension there's a special module name "this" which according to [1] always refers to the current package. But I couldn't find this rather useful feature mentioned in the GHC 7.6.1 Manual PackageImports section[2]. Has this been omitted on purpose from the documentation? Cheers, hvr [1]: https://github.com/ghc/ghc/commit/436a5fdbe0c9a466569abf1d501a6018aaa3e49e [2]: http://www.haskell.org/ghc/docs/latest/html/users_guide/syntax-extns.html#p…

2 2

Building GHC for BB10 (QNX)
by Stephen Paul Weber 12 Nov '12

12 Nov '12

Hey all, I'm interesting in trying to get an initial port for BlackBerry 10 (QNX) going. It's a POSIXish environment with primary interest in two architechtures: x86 (for simulator) and ARMv7 (for devices). I'm wondering if <http://hackage.haskell.org/trac/ghc/wiki/Building/Porting> is fairly up-to-date or not? Is there a better place I should be looking? One big difference (which may turn out to be a problem) is that the readily-available QNX compilers (gcc ports) are cross-compilers. I realise that GHC has no good support to act as a cross-compiler yet, and anticipate complications arising from trying to build GHC using a cross-compiler for bootstrapping (since that implies GHC acting as a cross-compiler at some point in the bootstrapping). Any suggestions would be very welcome. -- Stephen Paul Weber, @singpolyma See <http://singpolyma.net> for how I prefer to be contacted edition right joseph

2 1

How to use `trace` while debuging GHC
by Iavor Diatchki 12 Nov '12

12 Nov '12

Hello, While working on GHC sometimes I find it useful to dump the values of intermediate expressions, perhaps in the middle of pure code, using a combination of `trace` and `ppr`. The issue is that `ppr` returns an `SDoc`, and to turn an `SDoc` into a `String`, I need some `DynFlags`. There used to be a value called `tracingDynFlags` that I could use to dump values, but it has disappeared... Did it get moved somewhere, or is there a better way to get the same effect? -Iavor

4 3

Unexpected ambiguity in a seemingly valid Haskell 2010 program
by Roman Cheplyaka 11 Nov '12

11 Nov '12

For this module module Test where import System.Random data RPS = Rock | Paper | Scissors deriving (Show, Enum) instance Random RPS where random g = let (x, g') = randomR (0, 2) g in (toEnum x, g') randomR = undefined ghc (7.4.1 and 7.6.1) reports an error: rand.hs:9:9: No instance for (Random t0) arising from the ambiguity check for g' The type variable `t0' is ambiguous Possible fix: add a type signature that fixes these type variable(s) Note: there are several potential instances: instance Random RPS -- Defined at rand.hs:7:10 instance Random Bool -- Defined in `System.Random' instance Random Foreign.C.Types.CChar -- Defined in `System.Random' ...plus 34 others When checking that g' has the inferred type `g' Probable cause: the inferred type is ambiguous In the expression: let (x, g') = randomR (0, 2) g in (toEnum x, g') In an equation for `random': random g = let (x, g') = randomR ... g in (toEnum x, g') Failed, modules loaded: none. There should be no ambiguity since 'toEnum' determines the type of x (Int), and that in turn fixes types of 0 and 2. Interestingly, annotating 0 or 2 with the type makes the problem go away. jhc 0.8.0 compiles this module fine. Roman

4 7

Status of stack trace work
by Johan Tibell 08 Nov '12

08 Nov '12

Hi! I can't wait until we have some for of stack traces in GHC. What's the current status? Did the semantics you presented at HIW12 work out? Even though the full bells and whistles of full stack traces is something I'd really like to see, even their more impoverished cousins, the lexical stack trace, would be helpful in tracking down just which call to head gave rise to a "head: empty" list error. Once we do have some sort of stack traces, could we have throw automatically attach it to the exception, so we can get a printed stack trace upon crash? Is that how e.g. Java deals with that? Will that make other uses of exceptions (such as throwing async exceptions to kill threads) get much more expensive if we try to attach stack traces? A frequent user of async exceptions are web servers that start a timeout call per request. -- Johan

2 1

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 31 Oct '12

31 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