- Glasgow-haskell-users

Re: How to work around GHC bug
by Volker Wysk 14 Mar '12

14 Mar '12

Am Mittwoch 14 März 2012, 16:04:25 schrieben Sie: > I have $LANG = en_GB.UTF-8 and I am on mac os x, if that helps. Now we have the riddle, of why it works differently on your machine. However, e can leave it at that, I think. Happy hacking, Volker

1 0

Inlining and generic programming
by José Pedro Magalhães 14 Mar '12

14 Mar '12

Hello all, First of all, I'm sorry that this email is so absurdly long. But it's not easy to explain the problem at hand, so I took a step-by-step approach. The executive summary is: GHC can do a *great *job with inlining, but often it doesn't, and I don't understand why. So I have some questions, which are highlighted in the text below. In general, any insights regarding inlining or improving the performance of generics are welcome. My final goal is to be able to state that generic functions (in particular using GHC.Generics) will have no runtime overhead whatsoever when compared to a handwritten type-specific version. The setting Generic programming is based on representing datatypes in a uniform way using a small set of representation types. Functions defined on those representation types can then be applied to all datatypes, because we can convert between datatypes and their representations. However, generic functions tend to be slower than their specialised counterparts, because they have to deal with the conversions. But clever inlining (together with other compiler optimisations) can completely remove this overhead. The problem I'm tackling is how to tell GHC exactly what it should in the particular case of optimisation of generic code. Simplified example I'll focus on the problem of optimising a non-trivial function for generic enumeration of terms. My experience shows that GHC does quite good at optimising simple functions, especially consumers (like generic equality). But producers are trickier. First, we'll need some auxiliary functions: -- | Interleave elements from two lists. Similar to (++), but swap left and > -- right arguments on every recursive application. > -- > -- From Mark Jones' talk at AFP2008 > {-# NOINLINE (|||) #-} > (|||) :: [a] -> [a] -> [a] > [] ||| ys = ys > (x:xs) ||| ys = x : ys ||| xs > > > -- | Diagonalization of nested lists. Ensure that some elements from every > -- sublist will be included. Handles infinite sublists. > -- > -- From Mark Jones' talk at AFP2008 > {-# NOINLINE diag #-} > diag :: [[a]] -> [a] > diag = concat . foldr skew [] . map (map (\x -> [x])) > > skew :: [[a]] -> [[a]] -> [[a]] > skew [] ys = ys > skew (x:xs) ys = x : combine (++) xs ys > > combine :: (a -> a -> a) -> [a] -> [a] -> [a] > combine _ xs [] = xs > combine _ [] ys = ys > combine f (x:xs) (y:ys) = f x y : combine f xs ys > The particular implementation of these functions doesn't really matter. What's important is that we have a way to interleave lists (|||) and a way to diagonalise a matrix into a list (diag). We mark these functions as NOINLINE because inlining them will only make the core code more complicated (and may prevent rules from firing). Suppose we have a type of Peano natural numbers: data Nat = Ze | Su Nat deriving Eq > Implementing enumeration on this type is simple: enumNat :: [Nat] > enumNat = [Ze] ||| map Su enumNat > Now, a generic representation of Nat in terms of sums and products could look something like this: type RepNat = Either () Nat > That is, either a singleton (for the Ze case) or a Nat (for the Su case). Note that I am building a shallow representation, since at the leaves we have Nat, and not RepNat. This mimics the situation with current generic programming libraries (in particular GHC.Generics). We'll need a way to convert between RepNat and Nat: toNat :: RepNat -> Nat > toNat (Left ()) = Ze > toNat (Right n) = Su n > > fromNat :: Nat -> RepNat > fromNat Ze = Left () > fromNat (Su n) = Right n > (In fact, since we're only dealing with a generic producer we won't need the fromNat function.) To get an enumeration for RepNat, we first need to know how to enumerate units and sums: enumU :: [()] > enumU = [()] > > enumEither :: [a] -> [b] -> [Either a b] > enumEither ea eb = map Left ea ||| map Right eb > Now we can define an enumeration for RepNat: enumRepNat :: [RepNat] > enumRepNat = enumEither enumU enumNatFromRep > With the conversion function toNat, we can use enumRepNat to get an enumeration for Nat directly: enumNatFromRep :: [Nat] > enumNatFromRep = map toNat enumRepNat > First, convince yourself that enumNatFromRep and enumNat are equivalent functions: take 100 enumNat == take 100 enumNatFromRep > Now, what I want is that enumNatFromRep generates the same core code as enumNat. That should be possible; here are the necessary steps: map toNat enumRepNat > > == { inline enumRepNat } > > map toNat (enumEither enumU enumNatFromRep) > > == { inline enumEither } > > map toNat (map Left enumU ||| map Right enumNatFromRep) > > == { inline enumU } > > map toNat (map Left [()] ||| map Right enumNatFromRep) > > == { inline map } > > map toNat ([Left ()] ||| map Right enumNatFromRep) > > == { free theorem (|||): forall f a b. map f (a ||| b) = map f a ||| map f > b } > > map toNat [Left ()] ||| map toNat (map Right enumNatFromRep) > > == { inline map } > > [toNat (Left ())] ||| map toNat (map Right enumNatFromRep) > > == { definition of toNat (or inline toNat + case of constant) } > > [Ze] ||| map toNat (map Right enumNatFromRep) > > == { functor composition law: forall f g l. map f (map g l) = map (f . g) > l } > > [Ze] ||| map (toNat . Right) enumNatFromRep > > == { definition of toNat (or inline toNat + case of constant) } > > [Ze] ||| map Su enumNatFromRep > Now let's see what the compiler generates. I'm using GHC-7.4.1. Let's compile with -O1 and use -ddump-simpl to see the final simplifier output (core code) for enumNatFromRep: EnumAlone.enumNatFromRep :: [EnumAlone.Nat] > [GblId, > Str=DmdType, > Unf=Unf{Src=<vanilla>, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=IF_ARGS [] 30 0}] > EnumAlone.enumNatFromRep = > GHC.Base.map > @ EnumAlone.RepNat > @ EnumAlone.Nat > EnumAlone.toNat > EnumAlone.enumRepNat > > EnumAlone.enumRepNat [Occ=LoopBreaker] :: [EnumAlone.RepNat] > [GblId, Str=DmdType] > EnumAlone.enumRepNat = > EnumAlone.||| > @ (Data.Either.Either () EnumAlone.Nat) lvl4_rvV lvl5_rvW > Ah, it didn't even inline enumRepNat because it made it a loop breaker. We certainly want to inline it, so let's add a pragma: {-# INLINE enumRepNat #-} > Recompiling, we get: EnumAlone.enumRepNat [InlPrag=INLINE (sat-args=0)] > :: [EnumAlone.RepNat] > [GblId, > Str=DmdType, > Unf=Unf{Src=InlineStable, TopLvl=True, Arity=0, Value=False, > ConLike=False, Cheap=False, Expandable=False, > Guidance=ALWAYS_IF(unsat_ok=False,boring_ok=False) > Tmpl= EnumAlone.enumEither > @ () @ EnumAlone.Nat EnumAlone.enumU > EnumAlone.enumNatFromRep}] > EnumAlone.enumRepNat = > EnumAlone.||| > @ (Data.Either.Either () EnumAlone.Nat) lvl4_rvV lvl5_rvW > > EnumAlone.enumNatFromRep [Occ=LoopBreaker] :: [EnumAlone.Nat] > [GblId, Str=DmdType] > EnumAlone.enumNatFromRep = > GHC.Base.map > @ EnumAlone.RepNat > @ EnumAlone.Nat > EnumAlone.toNat > EnumAlone.enumRepNat > So no real difference in the generated code, other than the reassignment of loop breakers. For some reason enumRepNat still doesn't get inlined. *Question: why won't GHC inline enumRepNat, even when I tell it to do so with an INLINE pragma?* Well, let's inline it ourselves, then. We redefine enumNatFromRep to: enumNatFromRep = map toNat (enumEither enumU enumNatFromRep) > This however doesn't help much. We get the following core: lvl6_rw5 :: [Data.Either.Either () EnumAlone.Nat] > [GblId] > lvl6_rw5 = > EnumAlone.||| > @ (Data.Either.Either () EnumAlone.Nat) lvl4_rw3 lvl5_rw4 > > EnumAlone.enumNatFromRep [Occ=LoopBreaker] :: [EnumAlone.Nat] > [GblId, Str=DmdType] > EnumAlone.enumNatFromRep = > GHC.Base.map > @ EnumAlone.RepNat @ EnumAlone.Nat EnumAlone.toNat lvl6_rw5 > GHC is really keen on floating that (|||) out. Let's be very explicit about inlining: {-# INLINE toNat #-} > {-# INLINE enumU #-} > {-# INLINE enumEither #-} > Also, maybe it's floating it out because it doesn't have anything else to do to it. Let's add the free theorem of (|||) as a rule: {-# RULES "ft |||" forall f a b. map f (a ||| b) = map f a ||| map f b #-} > We needed this in our manual derivation, so GHC should need it too. Recompiling, we see we've made some progress: lvl5_ryv :: [Data.Either.Either () EnumAlone.Nat] > [GblId] > lvl5_ryv = > GHC.Base.map > @ EnumAlone.Nat > @ (Data.Either.Either () EnumAlone.Nat) > (Data.Either.Right @ () @ EnumAlone.Nat) > EnumAlone.enumNatFromRep > > lvl6_ryw :: [EnumAlone.Nat] > [GblId] > lvl6_ryw = > GHC.Base.map > @ (Data.Either.Either () EnumAlone.Nat) > @ EnumAlone.Nat > EnumAlone.toNat > lvl5_ryv > > EnumAlone.enumNatFromRep [Occ=LoopBreaker] :: [EnumAlone.Nat] > [GblId, Str=DmdType] > EnumAlone.enumNatFromRep = > EnumAlone.||| @ EnumAlone.Nat lvl4_ryu lvl6_ryw > enumNatFromRep finally starts with (|||) directly. But its second argument, lvl6_ryw, is a map of lvl5_ryv, which is itself a map! At this stage I expected GHC to be aware of the fusion law for map, but it seems that it isn't. *Question: why is map fusion not happening automatically?* Let's add it as a rule: {-# RULES "map/map1" forall f g l. map f (map g l) = map (f . g) l #-} > And now we're in a much better situation: lvl3_ryD :: [Data.Either.Either () EnumAlone.Nat] > [GblId, Caf=NoCafRefs] > lvl3_ryD = > GHC.Types.: > @ (Data.Either.Either () EnumAlone.Nat) > EnumAlone.fromNat1 > (GHC.Types.[] @ (Data.Either.Either () EnumAlone.Nat)) > > lvl4_ryE :: [EnumAlone.Nat] > [GblId] > lvl4_ryE = > GHC.Base.map > @ (Data.Either.Either () EnumAlone.Nat) > @ EnumAlone.Nat > EnumAlone.toNat > lvl3_ryD > > lvl5_ryF :: [EnumAlone.Nat] > [GblId] > lvl5_ryF = > GHC.Base.map > @ EnumAlone.Nat > @ EnumAlone.Nat > EnumAlone.Su > EnumAlone.enumNatFromRep > > EnumAlone.enumNatFromRep [Occ=LoopBreaker] :: [EnumAlone.Nat] > [GblId, Str=DmdType] > EnumAlone.enumNatFromRep = > EnumAlone.||| @ EnumAlone.Nat lvl4_ryE lvl5_ryF > Note how toNat is entirely gone from the second part of the enumeration (lvl5_ryF). Strangely enough, the enumerator for Ze (lvl4_ryE) is still very complicated: map toNat ([Left ()]). Why doesn't GHC simplify this to just [Ze]? Apparently because GHC doesn't simplify map over a single element list. *Question: why doesn't GHC optimise map f [x] to [f x]?* Let's tell it to do so: {-# RULES "map/map2" forall f x. map f (x:[]) = (f x):[] #-} > Now we're finally where we wanted: lvl_ryA :: [EnumAlone.Nat] > [GblId, Caf=NoCafRefs] > lvl_ryA = > GHC.Types.: > @ EnumAlone.Nat EnumAlone.Ze (GHC.Types.[] @ EnumAlone.Nat) > > lvl3_ryD :: [EnumAlone.Nat] > [GblId] > lvl3_ryD = > GHC.Base.map > @ EnumAlone.Nat > @ EnumAlone.Nat > EnumAlone.Su > EnumAlone.enumNatFromRep > > EnumAlone.enumNatFromRep [Occ=LoopBreaker] :: [EnumAlone.Nat] > [GblId, Str=DmdType] > EnumAlone.enumNatFromRep = > EnumAlone.||| @ EnumAlone.Nat lvl_ryA lvl3_ryD > This is what I wanted: no more representation types (Either or ()), and the code looks exactly like what is generated for the handwritten enumNat. More realistic generic programming Now let's see if we can transport this to the setting of a generic programming library. I'll use a bare-bones version of GHC.Generics: infixr 5 :+: > infixr 6 :*: > > data U = U deriving (Show, Read) > data a :+: b = L a | R b deriving (Show, Read) > data a :*: b = a :*: b deriving (Show, Read) > newtype Var a = Var a deriving (Show, Read) > newtype Rec a = Rec a deriving (Show, Read) > > class Representable a where > type Rep a > to :: Rep a -> a > from :: a -> Rep a > Let's represent Nat in this library: instance Representable Nat where > type Rep Nat = U :+: (Rec Nat) > from Ze = L U > from (Su n) = R (Rec n) > to (L U) = Ze > to (R (Rec n)) = Su n > (Note, in particular, that we do not need INLINE pragmas on the from/to methods. This might just be because GHC thinks these are small and inlines them anyway, but in general we want to make sure they are inlined, so we typically use pragmas there.) Now we need to implement enumeration generically. We do this by giving an instance for each representation type: class GEnum' a where > genum' :: [a] > > instance GEnum' U where > {-# INLINE genum' #-} > genum' = [U] > > instance (GEnum a) => GEnum' (Rec a) where > {-# INLINE genum' #-} > genum' = map Rec genum > > instance (GEnum a) => GEnum' (Var a) where > {-# INLINE genum' #-} > genum' = map Var genum > > instance (GEnum' f, GEnum' g) => GEnum' (f :+: g) where > {-# INLINE genum' #-} > genum' = map L genum' ||| map R genum' > > instance (GEnum' f, GEnum' g) => GEnum' (f :*: g) where > {-# INLINE genum' #-} > --genum' = diag [ [ x :*: y | y <- genum' ] | x <- genum' ] > genum' = diag (map (\x -> map (\y -> x :*: y) genum') genum') > We explicitly tell GHC to inline each case, as before. Note that for products I'm not using the more natural list comprehension syntax because I don't quite understand how that gets translated into core. In the cases for Var and Rec we use genum from the GEnum class: class GEnum a where > genum :: [a] > {-# INLINE genum #-} > default genum :: (Representable a, GEnum' (Rep a)) => [a] > genum = map to genum' > GEnum' is the class used for instantiating the generic representation types, and GEnum is used for user types. We use a default signature to provide a default method that can be used when we have a Representable instance for the type in question. This makes instantiating Nat very easy: instance GEnum Nat > Unfortunately, the core code generated in this situation (with the same RULES as before) is not nice at all: Main.$fGEnumNat_$cgenum [Occ=LoopBreaker] :: [Base.Nat] > [GblId, Str=DmdType] > Main.$fGEnumNat_$cgenum = > GHC.Base.map > @ (Base.Rep Base.Nat) > @ Base.Nat > Base.$fRepresentableNat_$cto > (lvl37_r79y > `cast` (Sym (GEnum.NTCo:GEnum') <Base.U Base.:+: (Base.Rec Base.Nat)> > ; > (GEnum.GEnum' (Sym > (Base.TFCo:R:RepNat)) ; > GEnum.NTCo:GEnum' <Base.Rep > Base.Nat>) > :: [Base.C Base.Nat_Ze_ Base.U > Base.:+: Base.C Base.Nat_Su_ (Base.Rec Base.Nat)] > ~# > [Base.Rep Base.Nat])) > We see a map of the `to` function, which is definitely not what we want. Oddly enough, if we give an explicit definition of genum for Nat, with the inlined default... instance GEnum Nat where genum = map to genum' > ... then we get the optimised code we want: lvl34_r79p :: [Base.Nat] > [GblId, Caf=NoCafRefs] > lvl34_r79p = > GHC.Types.: @ Base.Nat Base.Ze (GHC.Types.[] @ Base.Nat) > > lvl35_r79q :: [Base.Nat] > [GblId] > lvl35_r79q = > GHC.Base.map @ Base.Nat @ Base.Nat Base.Su Main.$fGEnumNat_$cgenum > > Main.$fGEnumNat_$cgenum [Occ=LoopBreaker] :: [Base.Nat] > [GblId, Str=DmdType] > Main.$fGEnumNat_$cgenum = > GEnum.||| @ Base.Nat lvl34_r79p lvl35_r79q > Again, no representation types, no `to`, just the same code that is generated for enumNat. Perfect. But we had to avoid using the default definition, which is a pity. *Question: why won't GHC inline the default method of a class, even when I have a pragma telling it to do so?* Let's look at one more datatype, because Nat does not use products. So let's consider trees: data Tree a = Leaf | Bin a (Tree a) (Tree a) > > instance Representable (Tree a) where > type Rep (Tree a) = U :+: (Var a :*: Rec (Tree a) :*: Rec (Tree a)) > from (Bin x l r) = R (Var x :*: Rec l :*: Rec r) > from Leaf = L U > to (R (Var x :*: (Rec l) :*: (Rec r))) = Bin x l r > to (L U) = Leaf > We give a GEnum instance using the same trick as before: instance GEnum (Tree Int) where genum = map to genum' > (For simplicity only for trees of integers.) The generated code for trees is unfortunately not as nice: a2_r79M > :: [Base.Rec (Base.Tree GHC.Types.Int) > Base.:*: Base.Rec (Base.Tree GHC.Types.Int) > [GblId, Str=DmdType] > a2_r79M = > GEnum.diag > @ (Base.Rec (Base.Tree GHC.Types.Int) > Base.:*: Base.Rec (Base.Tree GHC.Types.Int)) > lvl8_r79L > > lvl9_r79N :: [Base.Tree GHC.Types.Int] > [GblId] > lvl9_r79N = > GHC.Base.map > @ (Base.Rec (Base.Tree GHC.Types.Int) > Base.:*: Base.Rec (Base.Tree GHC.Types.Int)) > @ (Base.Tree GHC.Types.Int) > lvl5_r79H > a2_r79M > > Main.$fGEnumTree_$cgenum [Occ=LoopBreaker] > :: [Base.Tree GHC.Types.Int] > [GblId, Str=DmdType] > Main.$fGEnumTree_$cgenum = > GEnum.||| @ (Base.Tree GHC.Types.Int) lvl4_r79G lvl9_r79N > Note how lvl9_r79N is a map over a2_r79M, and a2_r79M is a `diag`. Ok, we need the free theorem of `diag` to tell GHC how to commute the `diag` with map: {-# RULES "ft/diag" forall f l. map f (diag l) = diag (map (map f) l) #-} > Unfortunately this doesn't change the generated core code. With some more debugging looking at the generated code at each simplifier iteration, I believe that this is because a2_r79M got lifted out too soon, prevent the rule from applying. With some imagination I decided to try the -fno-full-laziness flag to prevent let-floating. I'm not sure this is a good idea in general, but in this particular case it gives much better results: a1_r72i :: [Base.Rec (Base.Tree GHC.Types.Int) > [GblId, Str=DmdType] > a1_r72i = > GHC.Base.map > @ (Base.Tree GHC.Types.Int) > @ (Base.Rec (Base.Tree GHC.Types.Int)) > ((\ (tpl_B1 :: Base.Tree GHC.Types.Int) -> tpl_B1) > `cast` (<Base.Tree GHC.Types.Int> > -> Sym (Base.NTCo:Rec <Base.Tree GHC.Types.Int>) > :: (Base.Tree GHC.Types.Int -> Base.Tree GHC.Types.Int) > ~# > (Base.Tree GHC.Types.Int -> Base.Rec (Base.Tree > GHC.Types.Int)))) > Main.$fGEnumTree_$cgenum > > Main.$fGEnumTree_$cgenum [Occ=LoopBreaker] > :: [Base.Tree GHC.Types.Int] > [GblId, Str=DmdType] > Main.$fGEnumTree_$cgenum = > GEnum.||| > @ (Base.Tree GHC.Types.Int) > (GHC.Types.: > @ (Base.Tree GHC.Types.Int) > (Base.Leaf @ GHC.Types.Int) > (GHC.Types.[] @ (Base.Tree GHC.Types.Int))) > (GEnum.diag > @ (Base.Tree GHC.Types.Int) > (GHC.Base.map > @ (Base.Rec (Base.Tree GHC.Types.Int)) > @ [Base.Tree GHC.Types.Int] > (\ (x_a1yQ :: Base.Rec (Base.Tree GHC.Types.Int)) -> > GHC.Base.map > @ (Base.Rec (Base.Tree GHC.Types.Int)) > @ (Base.Tree GHC.Types.Int) > (\ (x1_X1zB :: Base.Rec (Base.Tree GHC.Types.Int)) -> > Base.Bin > @ GHC.Types.Int > a_r72h > (x_a1yQ > `cast` (Base.NTCo:Rec <Base.Tree GHC.Types.Int> > :: Base.Rec (Base.Tree GHC.Types.Int) ~# > Base.Tree GHC.Types.Int)) > (x1_X1zB > `cast` (Base.NTCo:Rec <Base.Tree GHC.Types.Int> > :: Base.Rec (Base.Tree GHC.Types.Int) ~# > Base.Tree GHC.Types.Int))) > a1_r72i) > a1_r72i)) > Note how our enum is now of the shape `[Leaf] ||| diag y`, which is good. The only catch is that there are some `Rec`s still laying around, with their associated newtype coercions, and a function a1_r72i that basically wraps the recursive enumeration in a Rec, only to be unwrapped in the body of `$fGEnumTree_$cgenum`. I don't know how to get GHC to simplify this code any further. *Question: why do I need -fno-full-laziness for the ft/diag rule to apply?* *Question: why is GHC not getting rid of the Rec newtype in this case?* I have also played with -O2, in particular because of the SpecConstr optimisation, but found that it does not affect these particular examples (perhaps it only becomes important with larger datatypes). I have also experimented with phase control in the rewrite rules and the inline pragmas, but didn't find it necessary for this example. In general, anyway, my experience with the inliner is that it is extremely fragile, especially across different GHC versions, and it's hard to get any guarantees of optimisation. I have also played with the -funfolding-* options before, with mixed results. [1] It's also a pity that certain flags are not explained in detail in the user's manual [2,3], like -fliberate-case, and -fspec-constr-count and threshold, for instance. Thank you for reading this. Any insights are welcome. In particular, I'm wondering if I might be missing some details regarding strictness. Cheers, Pedro [1] http://dreixel.net/research/pdf/ogie.pdf [2] http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html [3] http://www.haskell.org/ghc/docs/latest/html/users_guide/options-optimise.ht…

2 3

Bug with unicode characters in file names
by Volker Wysk 13 Mar '12

13 Mar '12

Hi This is some file "äöü.hs" with three German umlauts in the file name: main = putStrLn "äöü" Now I want to get the dependendency information. Therefore I call: ghc -M äöü.hs The following gets added to the Makefile: # DO NOT DELETE: Beginning of Haskell dependencies Ã¤Ã¶Ã¼.o : Ã¤Ã¶Ã¼.hs # DO NOT DELETE: End of Haskell dependencies The umlauts get transformed from three UTF-8 encoded characters (six bytes) to six UTF-8 encoded characters (twelve bytes). I'm sending this to glasgow-haskell-users instead of glasgow-haskell-bugs, because the latter does not seem to accept my messages. I receive nothing, neither the message in the mailing list, nor any error message. Bye, V.W.

3 2

packaged up polykinded types can't index type families?
by Nicolas Frisby 13 Mar '12

13 Mar '12

I suspect I'm tripping on a gap in the PolyKinds support. I'm trying to package up a type-level generic view. It uses PolyKinds — and DataKinds, but I think it's the PolyKinds that matter. If I compile everything locally in the same build, it works fine. If I isolate the spine view declarations in their own package, I get type errors. A quick search turned up this omnibus, which I'm guessing might fix my problem. http://hackage.haskell.org/trac/ghc/changeset/3bf54e78cfd4b94756e3f21c00ae1… I was hoping someone might be able to identify if that's the case. I can wait for 7.6.1 if I must, but I was wondering if there's a workaround. (If I avoid PolyKinds, it works. But I have to simulate PolyKinds for a finite set of kinds, which is pretty obfuscating and not general. If you're curious, checkout the type-spine package. This whole email regards my trying to generalize and simplify that package with PolyKinds.) In a distillation of my use case, we have two modules. The first is the type-level spine view. > {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds, TypeOperators, > UndecidableInstances, TemplateHaskell, EmptyDataDecls #-} > module Spine where > > type family Spine a :: * > > data Atom n -- represents a totally unapplied type name > data f :@ a -- |represents a type-level application > > -- this is an "unsaturated instance", which might be a no-no, but > -- at least isn't obviously causing the current problem > type instance Spine (f a) = f :@ a > > -- all other instances are for unapplied types names: > ----- e.g. type instance Spine N = Atom N > spineType :: Name -> Q [Dec] > spineType n = let t = conT n in > (:[]) `fmap` tySynInstD ''Spine [t] [t| Atom $t |] The second module is a distilled use case. > {-# LANGUAGE TypeFamilies, PolyKinds, DataKinds, TypeOperators, TemplateHaskell #-} > > module Test where > > import Spine -- our first module above > > type family IsApp (a :: *) :: Bool > type instance IsApp (Atom n) = False > type instance IsApp (a :@ b) = True > > -- example types and use > data A = A > data F a = F a > > concat `fmap` mapM spineType [''A, ''F] > > isApp :: (True ~ IsApp (Spine a)) => a -> () > isApp _ = () > > test :: () > test = isApp (F A) If Spine.hs and Test.hs are in the same directory and I load Test in ghci, it type-checks fine. If I instead use cabal to install Spine as its own package, the subsequent type-checking of Test.test fails with: > Couldn't match type `IsApp ((:@) (* -> *) * F A)' with `'True' The :bro Spine command returns the same information regardless of how Test imports Spine. > *Test> :bro Spine > type family Spine k a :: * > data Atom k n > data (:@) k k f a > spineType :: ...snip... Why can "IsApp (... :@ ...)" reduce if Spine was locally compiled but not if it's pulled from a package? Is there some crucial info that the package interfaces can't yet express? Is there an open bug for this? Thanks for your time, Nick

2 1

Boxed foreign prim
by Edward Kmett 13 Mar '12

13 Mar '12

I'm currently working with a lot of very short arrays of fixed length and as a thought experiment I thought I would try to play with fast numeric field accessors In particular, I'd like to use something like foreign prim to do something like > foreign import prim "cmm_getField" unsafeField# :: a -> Int# -> b > unsafeField :: a -> Int -> b > unsafeField a (I# i) = a' `pseq` unsafeField# a' i -- the pseq could be moved into the prim, I suppose. > where a' = unsafeCoerce a > fst :: (a,b) -> a > fst = unsafeField 0 > snd :: (a,b) -> b > snd = unsafeField 1 This becomes more reasonable to consider when you are forced to make something like > data V4 a = V4 a a a a using > unsafeIndex (V4 a _ _ _) 0 = a > unsafeIndex (V4 _ b _ _) 1 = b > unsafeIndex (V4 _ _ c _) 2 = c > unsafeIndex (V4 _ _ _ d) 3 = d rather than > unsafeIndex :: V4 a -> Int -> a > unsafeIndex = unsafeField But I can only pass unboxed types to foreign prim. Is this an intrinsic limitation or just an artifact of the use cases that have presented themselves to date?

4 6

Getting the file descriptor of a handle, without closing it
by Volker Wysk 12 Mar '12

12 Mar '12

Hello! A few months ago, I started a discussion about how to extract the file descriptor of a handle, without the side effect of closing the handle. Bas van Dijk kindly provided the following function: unsafeWithHandleFd :: Handle -> (Fd -> IO a) -> IO a (The action in the second argument is applied to the file descriptor of the handle in the first argument.) Now I'm trying to use it, but it appears to have a bug. This program shows it: snip---------------------------------------------------------------------- import IO import GHC.IO.Handle.Types -- haType, haDevice import GHC.IO.Handle.Internals -- withHandle', do_operation import System.Posix.Types -- Fd import System.IO.Error -- ioeSetErrorString import Data.Typeable -- cast import GHC.IO.Exception -- IllegalOperation import GHC.IO.FD hiding (stdin, stdout, stderr) -- fdFD import Foreign.C -- CInt import Control.Concurrent.MVar (MVar) main = do -- Works okay unsafeWithHandleFd stdin $ \fd -> putStrLn ("stdin: fd = " ++ show fd) -- Blocks unsafeWithHandleFd stdout $ \fd -> putStrLn ("stdout: fd = " ++ show fd) -- By Bas van Dijk unsafeWithHandleFd :: Handle -> (Fd -> IO a) -> IO a unsafeWithHandleFd h@(FileHandle _ m) f = unsafeWithHandleFd' h m f unsafeWithHandleFd h@(DuplexHandle _ _ w) f = unsafeWithHandleFd' h w f unsafeWithHandleFd' :: Handle -> MVar Handle__ -> (Fd -> IO a) -> IO a unsafeWithHandleFd' h m f = withHandle' "unsafeWithHandleFd" h m $ \h_@Handle__{haDevice} -> case cast haDevice of Nothing -> ioError (System.IO.Error.ioeSetErrorString (System.IO.Error.mkIOError IllegalOperation "unsafeWithHandleFd" (Just h) Nothing) "handle is not a file descriptor") Just fd -> do x <- f (Fd (GHC.IO.FD.fdFD fd)) return (h_, x) snip---------------------------------------------------------------------- The first call of unsafeWithHandleFd, works as expected. The second one blocks. I need unsafeWithHandleFd, or something similar, in order to port my HsShellScript library (http://volker-wysk.de/hsshellscript/index.html) to the current version of GHC. If someone who understands the internals of the GHC IO libraries, had a hint, or even a fix, I'd be very grateful. Sincerely, Volker Wysk

3 4

Unable to build GHC-7.4.1 on OpenIndiana
by Paul Graphov 11 Mar '12

11 Mar '12

Hello GHC-users! I'm trying to compile GHC-7.4.1 under OpenIndiana and get the following error all the time: ghc.mk:85: *** Make has restarted itself 2 times; is there a makefile bug?. Stop. I googled a bit and found that this can be a result of touching some files during build. But actually no files were touched, I've even restarted compilation from scratch to check it. Currently I have GHC-7.2.2. that was installed via http://pkg.openindiana.org/sfe, GNU Make 3.81 I use "quick" build flavour in build/build.mk (but it doesn't seem to matter) Also i've installed these packages to make it build: pkg install gcc pkg install system/header pkg install developer/library/lint pkg install header-math Thanks.

2 2

Emacs mode for reading Cmm
by Johan Tibell 09 Mar '12

09 Mar '12

Hi, I created a tiny Emacs mode for reading Cmm, which I found myself doing lately. The mode is focused on reading Cmm at the moment, not writing it. Patches are welcome. Installation: 1. Download cmm-mode.el from https://github.com/tibbe/cmm-mode 2. Put the file somewhere on your Emacs load path. 3. Add (require 'cmm-mode) to your Emacs init file. Files ending in .cmm will automatically use the Cmm mode. -- Johan

1 0

How unsafe are unsafeThawArray# and unsafeFreezeArray#
by Johan Tibell 09 Mar '12

09 Mar '12

Hi, I just ran across some code that calls unsafeThawArray#, writeArray#, and unsafeFreezeArray#, in that order. How unsafe is that? * Is it unsafe in the sense that if someone has a reference to the original Array# they will see the value of that pure array change? * Is it unsafe in the sense things will crash and burn? I looked at the implementation of unsafeFreezeArray#, which is emitPrimOp [res] UnsafeFreezeArrayOp [arg] _ = stmtsC [ setInfo arg (CmmLit (CmmLabel mkMAP_FROZEN_infoLabel)), CmmAssign (CmmLocal res) arg ] but I couldn't find any implementation of unsafeThawArray#. Is it a no-op? It seems to me that if unsafeFreezeArray# changes the head of the array heap object so should unsafeThawArray#. Cheers, Johan

5 6

Re: thoughts on the record update problem
by Gershom B 08 Mar '12

08 Mar '12

On Thu, Mar 8, 2012 at 4:52 PM, Greg Weber <greg(a)gregweber.info> wrote: > syntax we would like. Does that make sense? I take it that you agree > that we should separate the discussion of semantics from > implementation: this is a perfect example of why. If we can describe semantics without concern for the possibility/needs of implementation, then I've got some _great_ proposals I'd like to make! --Gershom

1 0