January 2013 - Glasgow-haskell-users

Request for review of a GADT tutorial draft
by Anton Dergunov 28 Jan '13

28 Jan '13

Dear Haskell community, I have recently written an introductory-level tutorial article about GADTs in GHC (inspired by LASER 2012 summer school and to be submitted to their proceedings). I have already send this draft to the "Haskell Cafe" mailing list, but I was also advised to use these mailing lists, so I would like to ask for your feedback: http://anton-dergunov.ru/publications/gadts_draft_v4.pdf Any opinion about this article and any suggestions are very welcome! -- Best Regards, Anton Dergunov

1 0

data kinds
by Ross Paterson 27 Jan '13

27 Jan '13

GHC implements data kinds by promoting data declarations of a certain restricted form, but I wonder if it would be better to have a special syntax for kind definitions, say data kind Nat = Zero | Succ Nat At the moment, things get promoted whether you need them or not, and if you've made some mistake that makes your definition non-promotable you don't find out until you try to use it. More importantly, a separate form for kinds would allow one to use existing kinds, i.e. *, in definitions of new kinds.

6 5

Re: Error building ghc on raspberry pi.
by roconnor＠theorem.ca 27 Jan '13

27 Jan '13

On Thu, 3 Jan 2013, Thijs Alkemade wrote: > I believe I had the same problem, which disappeared after upgrading llvm from 3.0 to 3.1, and using that instead for ./configure. > > Hope this helps, > Thijs Thanks, using LLVM 3.1 seems to have improved the siutation, but I'm running into a new error. Here is the error I get when trying to build GHC 7.6.1 from 7.4.1 ===--- building final phase make -r --no-print-directory -f ghc.mk phase=final all LD libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/debug.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/debug.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/longlong.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/longlong.o /usr/bin/ld: error: libraries/ghc-prim/dist-install/build/cbits/popcnt.o uses VFP register arguments, libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o does not /usr/bin/ld: failed to merge target specific data of file libraries/ghc-prim/dist-install/build/cbits/popcnt.o make[1]: *** [libraries/ghc-prim/dist-install/build/HSghc-prim-0.3.0.0.o] Error 1 I get similar errors when building GHC 7.4.1 (patched with http://hackage.haskell.org/trac/ghc/attachment/ticket/5914/0001-add-support…) Any of you encountered this problem before? -- Russell O'Connor <http://r6.ca/> ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.''

7 64

any successfull ghc registerised builds on arm?
by Nathan Hüsken 26 Jan '13

26 Jan '13

In a different thread (Error building ghc on raspberry pi): On 01/08/2013 12:27 PM, Thijs Alkemade wrote:(...) > > I did eventually finish building stage2, but the final executable segfaulted on start. > I haven't investigated much why that happened, the days it takes to rebuild it just > made me give up. Was that an registerised or unregisterised build? Did anyone succesfully build ghc on an arm system which produces non crashing executables? I am asking, because I build a arm-linux-androideabi cross compiler, but the executables crash. Only in an unregisterised build, they work. So I wonder if it is a general arm problem or has to do with android. Thanks! Nathan

7 38

GHCJS, JavaScript, cross-platform typechecking with the GHC API and primops
by Luite Stegeman 25 Jan '13

25 Jan '13

hi all, I've been working on GHCJS [1] for a while and am trying to get it to work on 64 bit GHC. A quick background: GHCJS uses the GHC API to generate STG, which it then translates to JavaScript. It uses slightly patched versions of the integer-gmp, base and ghc-prim libraries and supports many GHC features, including arrays and threading. All JavaScript numbers are essentially double precision floating point. With some tricks (using bitwise operators) it's possible to get reasonable 32 bit integer emulation out of it, but emulating 64 bit integers would be very slow. Therefore, if we compile Haskell to JavaScript, it should really be treated as a 32 bit target. Now this is a problem, with GHC 7.6 and lower, generated STG depended on the word size of the host, so it was simply impossible to do this with a 64 bit host. In HEAD, wORD_SIZE_IN_BITS is now in DynFlags, so I decided to have another go. I'm aiming for the following procedure to install GHCJS and build a package: # cabal install ghcjs -- installs `ghcjs`, `ghcjs-boot`, `ghcjs-pkg`, `ghcjs-cabal` # ghcjs-boot -- build ghc-prim, integer-gmp, base for GHCJS and register them in its package db # ghcjs-cabal install myPackage -- cabal wrapper that uses ghcjs instead of ghc GHCJS instructs the GHC API to build 32 bit code [2] and sets preprocessor definitions so that libraries also expect 32 bit code. Library patches include PrimOpWrappers in ghc-prim, which is generated from the 32 bit primops. But here's the problem: When typechecking PrimOpWrappers, the GHC API appears to use its own built-in types for everything in GHC.Prim, and there are differences between 32 bit and 64 bit (for example popCnt64# :: Word64# -> Word# on 32 bit, :: Word# -> Word# on 64), so you get lots of errors. Now I'm wondering, is there a way around this, or would it be reasonable to modify GHC to somehow have the primop types in DynFlags, instead of them being hardcoded in the compiler? luite [1] https://github.com/ghcjs/ghcjs (I'm mostly working in the Gen2 branch, an experimental faster code generator) [2] https://github.com/ghcjs/ghcjs/blob/gen2/src-bin/Compiler/Main.hs#L345

1 0

ghc passing -undef to preprocessor and thereby eliminating OS specific defines
by Nathan Hüsken 24 Jan '13

24 Jan '13

Hey, I am trying to adapt some code in the libraries when compiling for android (i.E. because some things are different on android to other posix systems). So in C code I would just do "#ifdef __ANDROID__". While in the *.h and *.c files it seems to work, it does not work in *.hs files. I noted that the preprocessor is run like this: arm-linux-androideabi-gcc -E -undef -traditional -fno-stack-protector -DTABLES_NEXT_TO_CODE The "-undef" parameter is causing the __ANDROID__ define to be removed. Does it make sense to pass "-undef" to the preprocessor? Any other Ideas how I could adapt the code for android? Thanks! Nathan

2 1

Cabal and cross compilation
by Nathan Hüsken 23 Jan '13

23 Jan '13

Hey, I am working on getting ghc to cross compile to android. When trying to get haskeline to compile. I want to change the cabal file such that it sets a flag when compiling for android. For that I changed cabal so that it recognizes android as a OS. But cabal seems to get its os information from System.Info.os, and from what I can tell this always returns the host os and not the target os. Am I getting this right, is cabal unaware of the target os? How can we change this? Regards, Nathan

3 2

Newtype wrappers
by Simon Peyton-Jones 22 Jan '13

22 Jan '13

Friends I'd like to propose a way to "promote" newtypes over their enclosing type. Here's the writeup http://hackage.haskell.org/trac/ghc/wiki/NewtypeWrappers Any comments? Below is the problem statement, taken from the above page. I'd appreciate * A sense of whether you care. Does this matter? * Improvements to the design I propose Simon The problem Suppose we have newtype Age = MkAge Int Then if n :: Int, we can convert n to an Age thus: MkAge n :: Age. Moreover, this conversion is a type conversion only, and involves no runtime instructions whatsoever. This cost model -- that newtypes are free -- is important to Haskell programmers, and encourages them to use newtypes freely to express type distinctions without introducing runtime overhead. Alas, the newtype cost model breaks down when we involve other data structures. Suppose we have these declarations data T a = TLeaf a | TNode (Tree a) (Tree a) data S m a = SLeaf (m a) | SNode (S m a) (S m a) and we have these variables in scope x1 :: [Int] x2 :: Char -> Int x3 :: T Int x4 :: S IO Int Can we convert these into the corresponding forms where the Int is replaced by Age? Alas, not easily, and certainly not without overhead. * For x1 we can write map MkAge x1 :: [Age]. But this does not follow the newtype cost model: there will be runtime overhead from executing the map at runtime, and sharing will be lost too. Could GHC optimise the map somehow? This is hard; apart from anything else, how would GHC know that map was special? And it it gets worse. * For x2 we'd have to eta-expand: (\y -> MkAge (x2 y)) :: Char -> Age. But this isn't good either, because eta exapansion isn't semantically valid (if x2 was bottom, seq could distinguish the two). See #7542<http://hackage.haskell.org/trac/ghc/ticket/7542> for a real life example. * For x3, we'd have to map over T, thus mapT MkAge x3. But what if mapT didn't exist? We'd have to make it. And not all data types have maps. S is a harder one: you could only map over S-values if m was a functor. There's a lot of discussion abou this on #2110<http://hackage.haskell.org/trac/ghc/ticket/2110>.

18 40

Global constant propagation
by C Rodrigues 21 Jan '13

21 Jan '13

I'm curious about global constant propagation in GHC. It's a fairly basic optimization in the CFG-based compiler domain, and it's similar to constructor specialization, but it doesn't seem to be in GHC's repertoire. Perhaps it's usually subsumed by other optimizations or it's more complicated than I am thinking. Is this optimization worth implementing? This optimization can help when a case expression returns a product, some fields of which are the same in all branches. The following program is a minimal example of an optimizable situation that GHC doesn't exploit. {-# OPTIONS_GHC -O3 -funbox-strict-fields #-} data D = D !Int !Int foo n = if n > 0 then D 0 0 else D 0 n main = case foo $ read "7" of D x y -> if x == 0 then return () else print y >> putStrLn "A" After inlining and case-of-case transformation, GHC produces main = let n = read "7" k x y = case x of {0 -> return (); _ -> print y >> putStrLn "A"} in if n > 0 then k 0 0 else k 0 n If the simplifier could discover that x is always 0, it could eliminate one parameter of 'k' and the case expression.

2 1

Updating/understanding code from implicit configurations paper
by Eric M. Pashman 19 Jan '13

19 Jan '13

Reading the implicit configurations paper (Kiselyov & Shan), I couldn't figure out how this bit of code (section 3.2) was meant to work: class Modular s a | s -> a where modulus :: s -> a normalize :: (Modular s a, Integral a) => a -> M s a normalize a :: M s a = M (mod a (modulus (undefined :: s))) Here, `M` is just a type representing a modulus, with a phantom parameter that's going to make the magic happen: data M s a = M a deriving (Eq, Show) Running this in GHC 7.4.2, with the extensions for scope typed variables, multi parameter type classes, and functional dependencies enabled, I get a parse error on the type signature on the LHS of the definition of `normalize`. Having moved the deprecated LHS result annotation to the RHS, I think this should be equivalent: normalize :: (Modular s a, Integral a) => a -> M s a normalize x = (M (mod x (modulus (undefined :: s)))) :: M s a But indeed this won't type-check. I've tried annotating the argument (x :: a) and the result of `modulus` (modulus (undefined :: s) :: a), as well as various other terms, but GHC always tells me the phantom type is ambiguous or the type of the argument of `normalize` can't be unified with the parameter `a` in the result type. Now, like I said, I didn't see how this could work in the first place, so I'm at a loss as to what the problem is. Can someone show me how to get this to compile with a recent version of GHC? I'd also appreciate any insight into what `normalize` is meant to do, if the working code turns out to differ in just a type annotation or two. ... Regards, Eric PS: The literate Haskell version of the paper is here.

2 2