November 2012 - Glasgow-haskell-users

Dynamic libraries by default and GHC 7.8
by Ian Lynagh 06 Dec '12

06 Dec '12

Hi all, GHC HEAD now has support for using dynamic libraries by default (and in particular, using dynamic libraries and the system linker in GHCi) for a number of platforms. This has some advantages and some disadvantages, so we need to make a decision about what we want to do in GHC 7.8. There are also some policy questions we need to answer about how Cabal will work with a GHC that uses dynamic libraries by default. We would like to make these as soon as possible, so that GHC 7.6.2 can ship with a Cabal that works correctly. The various issues are described in a wiki page here: http://hackage.haskell.org/trac/ghc/wiki/DynamicByDefault If you have a few minutes to read it then we'd be glad to hear your feedback, to help us in making our decisions Thanks Ian -- Ian Lynagh, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/

21 60

GHC Performance Tsar
by Simon Peyton-Jones 06 Dec '12

06 Dec '12

| > While writing a new nofib benchmark today I found myself wondering | > whether all the nofib benchmarks are run just before each release, I think we could do with a GHC Performance Tsar. Especially now that Simon has changed jobs, we need to try even harder to broaden the base of people who help with GHC. It would be amazing to have someone who was willing to: * Run nofib benchmarks regularly, and publish the results * Keep baseline figures for GHC 7.6, 7.4, etc so we can keep track of regressions * Investigate regressions to see where they come from; ideally propose fixes. * Extend nofib to contain more representative programs (as Johan is currently doing). That would help keep us on the straight and narrow. Any offers? It could be more than one person. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell- | users-bounces(a)haskell.org] On Behalf Of Simon Marlow | Sent: 30 November 2012 12:11 | To: Johan Tibell | Cc: glasgow-haskell-users | Subject: Re: Is the GHC release process documented? | | On 30/11/12 03:54, Johan Tibell wrote: | > While writing a new nofib benchmark today I found myself wondering | > whether all the nofib benchmarks are run just before each release, | > which the drove me to go look for a document describing the release | > process. A quick search didn't turn up anything, so I thought I'd ask | > instead. Is there a documented GHC release process? Does it include | > running nofib? If not, may I propose that we do so before each release | > and compare the result to the previous release*. | > | > * This likely means that nofib has to be run for the upcoming release | > and the prior release each time a release is made, as numbers don't | > translate well between machines so storing the results somewhere is | > likely not that useful. | | I used to do this on an ad-hoc basis: the nightly builds at MSR spit out | nofib results that I compared against previous releases. | | In practice you want to do this much earlier than just before a release, | because it can take time to investigate and squash any discrepancies. | | On the subject of the release process, I believe Ian has a checklist | that he keeps promising to put on the wiki (nudge :)). | | Cheers, | Simon | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

11 14

Re: lambda case
by Herbert Valerio Riedel 03 Dec '12

03 Dec '12

Jon Fairbairn <jon.fairbairn(a)cl.cam.ac.uk> writes: [...] > “\case” complicates lambda, using “of” simply breaks “case … of …” > into two easily understood parts. Just some observation (I'm rather late to the lambda-case discussion, so this might have been already pointed out previously): if the reserved keyword 'of' was to take the place of '\case', shouldn't then 'case' exp w/o the "'of' { alts }"-part become a separately valid expression (with 'case' essentially meaning 'flip ($)') to really break it up into two independent parts? Then 'case exp of { alts }' wouldn't be a special form anymore, but would just result from combining 'case' and 'of'; 'case' wouldn't even need to be a reserved keyword (and thus the grammar could be simplified), if it wasn't for the current grammar which requires to isolate a \case-expression by using () or $, consider e.g.: {-# LANGUAGE LambdaCase #-} import System.Environment case' :: b -> (b -> c) -> c case' = flip ($) main = do s <- getArgs case' s $ \case -- image '\case' was actually '\of' or 'of' [x] -> putStrLn ("Hello " ++ x) _ -> putStrLn "wrong number of arguments given" just my 2¢ cheers, hvr

5 5

Is the GHC release process documented?
by Johan Tibell 30 Nov '12

30 Nov '12

Friends, While writing a new nofib benchmark today I found myself wondering whether all the nofib benchmarks are run just before each release, which the drove me to go look for a document describing the release process. A quick search didn't turn up anything, so I thought I'd ask instead. Is there a documented GHC release process? Does it include running nofib? If not, may I propose that we do so before each release and compare the result to the previous release*. * This likely means that nofib has to be run for the upcoming release and the prior release each time a release is made, as numbers don't translate well between machines so storing the results somewhere is likely not that useful. Cheers, Johan

2 1

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

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 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

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