- Glasgow-haskell-users

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

30 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

Computing the final representation type of a TyCon (Was: Unpack primitive types by default in data)
by Johan Tibell 29 Nov '12

29 Nov '12

Hi all, I've decided to try to implement the proposal included in the end of this message. To do so I need to write a function hasPointerSizedRepr :: TyCon -> Bool This function would check that that the TyCon is either * a newtype, which representation type has a pointer-sized representation, or * an algebraic data type, with one field that has a pointer-sized representation. I'm kinda lost in all the data types that GHC defines to represent types. I've gotten no further than hasPointerSizedRepr :: TyCon -> Bool hasPointerSizedRepr tc@(AlgTyCon {}) = case algTcRhs tc of DataTyCon{ data_cons = [data_con] } -> ... NewTyCon { data_con = [data_con] } -> ... _ -> False hasPointerSizedRepr _ = False I could use some pointers (no pun intended!) at this point. The function ought to return True for all the following types: data A = A Int# newtype B = B A data C = C !B data D = D !C data E = E !() data F = F !D One part that confuses me is figuring out the representation type of a data constructor after unpacking. For example, the function should not return true if called on G in this example: data G = G !H data H = H {-# UNPACK #-} !I data I = I !Int !Int because if we unpacked H into G's constructor it would take up two words, due to I being unpacked. Does DataCon contain the unpacked representation of the data constructor or only the before-optimizations representation? Cheers, Johan On Thu, Feb 16, 2012 at 4:25 PM, Johan Tibell <johan.tibell(a)gmail.com> wrote: > Hi all, > > I've been thinking about this some more and I think we should > definitely unpack primitive types (e.g. Int, Word, Float, Double, > Char) by default. > > The worry is that reboxing will cost us, but I realized today that at > least one other language, Java, does this already today and even > though it hurts performance in some cases, it seems to be a win on > average. In Java all primitive fields get auto-boxed/unboxed when > stored in polymorphic fields (e.g. in a HashMap which stores keys and > fields as Object pointers.) This seems analogous to our case, except > we might also unbox when calling lazy functions. > > Here's an idea of how to test this hypothesis: > > 1. Get a bunch of benchmarks. > 2. Change GHC to make UNPACK a no-op for primitive types (as library > authors have already worked around the lack of unpacking by using this > pragma.) > 3. Run the benchmarks. > 4. Change GHC to always unpack primitive types (regardless of the > presence of an UNPACK pragma.) > 5. Run the benchmarks. > 6. Compare the results. > > Number (1) might be what's keeping us back right now, as we feel that > we don't have a good benchmark set. I suggest we try with nofib first > and see if there's a different and then move on to e.g. the shootout > benchmarks. > > I imagine that ignoring UNPACK pragmas selectively wouldn't be too > hard. Where the relevant code? > > Cheers, > Johan

1 1

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

27 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

fatal error with ghci and llvm
by José Romildo Malaquias 23 Nov '12

23 Nov '12

Hello. When experimenting with the module LLVM.Core in GHCi on my gentoo linux system, I have got a fatal error: $ ghci GHCi, version 7.6.1: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Prelude> :m + LLVM.Core Prelude LLVM.Core> IntEQ Loading package llvm-base-3.0.1.0 ... GHCi runtime linker: fatal error: I found a duplicate definition for symbol LLVMAddAlwaysInlinerPass whilst processing object file /usr/lib64/llvm/libLLVMipo.a This could be caused by: * Loading two different object files which export the same symbol * Specifying the same object file twice on the GHCi command line * An incorrect `package.conf' entry, causing some object to be loaded twice. GHCi cannot safely continue in this situation. Exiting now. Sorry. Any clues?

2 2

Leaving Microsoft
by Simon Marlow 23 Nov '12

23 Nov '12

Today I'm announcing that I'm leaving Microsoft Research. My plan is to take a break to finish the book on Parallel and Concurrent Haskell for O'Reilly, before taking up a position at Facebook in the UK in March 2013. This is undoubtedly a big change, both for me and for the Haskell community. I'll be stepping back from full-time GHC development and research and heading into industry, hopefully to use Haskell. It's an incredibly exciting opportunity for me, and one that I hope will ultimately be a good thing for Haskell too. What does this mean for GHC? Obviously I'll have much less time to work on GHC, but I do hope to find time to fix a few bugs and keep things working smoothly. Simon Peyton Jones will still be leading the project, and we'll still have support from Ian Lynagh, and of course the community of regular contributors. Things are in a reasonably stable state - there haven't been any major architectural changes in the RTS lately, and while we have just completed the switchover to the new code generator, I've been working over the past few weeks to squeeze out all the bugs I can find, and I'll continue to do that over the coming months up to the 7.8.1 release. In due course I hope that GHC can attract more of you talented hackers to climb the learning curve and start working on the internals, in particular the runtime and code generators, and I'll do my best to help that happen. Cheers, Simon

2 1

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

Promoted types accepted without language extensions
by Sean Leather 19 Nov '12

19 Nov '12

We discovered that GHC and GHCi (7.4.1) accept promoted types without specifying language extensions (and even when specifying -XHaskell98). For example, promoted lists are accepted: Prelude> type T = [Int,Char] Prelude> :i T type T = (:) * Int ((:) * Char ([] *)) -- Defined at <interactive>:2:6 Also, promoted datatypes: > data N = Z > type T = 'Z I'm guessing you can't use these types anywhere (since they are not kind *), so they won't be very useful, but it seems like this should be disallowed. Regards, Sean

2 1

Generating random type-level naturals
by Eric M. Pashman 17 Nov '12

17 Nov '12

I've been playing around with the idea of writing a genetic programming implementation based on the ideas behind HList. Using type-level programming, it's fairly straighforward to put together a program representation that's strongly typed, that supports polymorphism, and that permits only well-typed programs by construction. This has obvious advantages over vanilla GP implementations. But it's impossible to generate arbitrary programs in such a representation using standard Haskell. Imagine that you have an HList-style heterogenous list of arbitrarily typed Haskell values. It would be nice to be able to pull values from this collection at random and use them to build up random programs. But that's not possible because one can't write a function that outputs a value of arbitrary type. (Or, more or less equivalently, one can't write dependently typed functions, and trying to fake it at the type-level leads to the original problem.) One can, however, write a bit of Template Haskell to construct a random HNat. Something like, hNat 0 = [| hZero |] hNat n = [| hSucc $(hNat (n - 1)) |] Call that with a random positive integer inside a splice and Template Haskell will give you a random HNat that you can use to index an HList. There's your arbitrary Haskell value. But this technique is of little practical value since it only works at compile-time. I've fiddled around with the hint library, trying to interpret the Template Haskell to get random HNats at run-time. This works, sort of, but there's no way to "liberate" the generated HNat because hint's `interpret` function requires a type witness. A look-alike string from the `eval` function is as close as you can get. Is there some dirty trick provided by the GHC API that would allow me to bind the generated HNat to a name and pass it around in a way similar to what GHCi seems to do? I realize that I probably have a grossly optimistic idea of what magic GHCi is performing when it interprets user input in a way that seems to allow this sort of thing. To summarize, I'm basically trying to wrap up the following process programmatically: ghci> n <- randomInt -- A random Int ghci> :load SomeModule.hs -- Contains `hNat` as above ghci> let hn = $(hNat n) -- Voila, a random HNat ghci> ... -- Do stuff with `hn`, then repeat Is something along the lines of what I'm imagining possible? If not, can I get close enough for my purposes? General insights and commentary are welcome as well. Regards, Eric

5 5

UHC-like JavaScript backend in GHC
by Jurriën Stutterheim 14 Nov '12

14 Nov '12

Hi all, Last year, I worked on improving the Utrecht Haskell Compiler (UHC) JavaScript backend[1] up to the point where it is now possible to write complete JavaScript applications with it. Alessandro Vermeulen then ported one of my web applications to the UHC JS backend, and we've started using the result of that in production afterwards. The result of these efforts were presented at IFL 2012 and HIW 2012 by Alessandro and Atze Dijkstra respectively. One of the most powerful new features of this backend, in addition to the customised RTS, is the small subset of JS we can use when importing JavaScript functions with the "js" calling convention. For example, we can import the push() method for arrays using (roughly) the following import declaration: foreign import js "%1.push(%2)" push :: JSArray a -> a -> IO (JSArray a) Here, we write a small expression in the import declaration, in which the object and arguments are numbered. The object argument, %1, corresponds to the `JSArray a` in the type signature of `push`, while the method argument %2 corresponds with the `a` in the type signature. Chris Done drew inspiration from this calling convention in designing the FFI for his Fay programming language[2]. One of UHC's nice features is that it is very easy to extend it, due to its heavy use of attribute grammars and its sophisticated variability management. Working on, and extending the UHC JavaScript backend was relatively easy because of this. One of UHC's downsides, however, is that it lags behind on supporting advanced language features, such as GADTs, functional dependencies, type families, etc. As a result, only a limited number of packages from Hackage can be compiled with UHC. In addition, some code requires additional workarounds and explicit type signatures, which would be redundant if, e.g., fundeps would be available. In an ideal situation, we can have both the js calling convention from UHC's JavaScript backend, and GHC's more advanced language support. Combined, we can use most libraries on Hackage, we don't have to worry about the lack of language support while designing our JS applications, and we don't have to use explicit type annotations in scenarios where, e.g. fundeps, would un-ambiguate the situation quite easily. In the near future (i.e. after I have finished my MSc thesis), I would like to get started with getting more familiar with GHC's internals. In particular, I would like to see if it is possible to implement the js calling convention in GHC and have GHC spit out JavaScript, much like UHC is currently doing. Before I get started: does the GHC architecture currently allow for adding a new calling convention which departs from the conventional C FFIs and introduces a custom RTS? If not, where are the current major bottlenecks? And would it be possible to remove these bottlenecks, without significantly affecting the compilation times, and without affecting the performance of generated native code (when the JS backend is not used)? Any input on this is appreciated :) Cheers, Jurriën [1] http://uu-computerscience.github.com/uhc-js/ [2] http://fay-lang.org

5 8

Where has the special built-in inline function gone?
by Johan Tibell 13 Nov '12

13 Nov '12

Hi all, For the first time, I wanted to use the special built-in inline function. To my dismay, I can't find it anywhere! Here's a minimal example: --8<--------- module Main where import GHC.Prim f x = x + 1 {-# INLINE f #-} g h x = inline h x main = print $ g f 1 --8<--------- $ ghc /tmp/Repro.hs [1 of 1] Compiling Main ( /tmp/Repro.hs, /tmp/Repro.o ) /tmp/Repro.hs:8:9: Not in scope: `inline' Perhaps you meant `unlines' (imported from Prelude) $ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.4.1 -- Johan

2 2