June 2011 - Glasgow-haskell-users

GHC and Haskell 98
by Simon Peyton-Jones 24 Jun '11

24 Jun '11

Friends, this is to ask your opinion about a possible change in GHC 7.2. The current implementation in GHC 7.2 is Plan A below. Plan A is a bit easier for us, but I think it may be a bit draconian, and therefore propose Plan B as an alternative. Opinions? Simon ============================================== With GHC 7.0 if you say ghc -c Main.hs the import of Prelude, whether implicit or explicit, will come from package 'base'. This is also true if you say ghc -c Main.hs -package haskell98 The package 'haskell98' exposes 'List' and 'Random' but not 'Prelude'. That still comes from 'base'. This isn't good, because it means that if in the future we change 'Prelude' in package 'base', a Haskell98 module might fail to compile. And later iterations of Haskell might well want to expand or change the Prelude. There appear to be two alternatives: (Plan A) Add a module 'Prelude' to package 'haskell98'. Now you can compile a pure H98 program thus: ghc -c Main.hs -hide-all-packages -package haskell98 (Cabal puts the -hide-all-packages in for you.) And this will continue to work even if later iterations of Haskell change the Prelude. BUT (A) means that this module becomes un-compilable: module Main where import Random import Data.List Why? Because 'Random' comes from 'haskell98' and 'Data.List' comes from 'base'. But if you say ghc -c Main.hs -package base -package haskell98 then the (implicit) import of 'Prelude' will say "Ambiguous module name: Prelude", because it's exported by both 'base' and 'haskell98'. To fix this you have to change 'import Random' to 'import System.Random'. But the latter's API is different, so you may have to change the source code that uses it. So the second alternative is this: (Plan B) Like Plan A, but in addition, if you say "{-# LANGUAGE Haskell98 #-}" in the file, or -XHaskell98 on the command line, the implicit import of Prelude comes from package 'haskell98', provided -package haskell98 is specified, but regardless of what other in-scope packages expose a Prelude module. Variation: an explicit 'import Prelude' is similarly directed to package 'haskell98' as well. So: Under Plan A, some Hackage packages will become un-compilable, and will require source code changes to fix them. I do not have any idea how many Hackage packages would fail in this way. Unser Plan B, Hackage package that compile now will continue to compile, if their Cabal file is altered. No source code changes. (Well, unless they depend on some innards of GHC.IO or something like that.) But Plan A is simpler. And by breaking packages it will encourage [force] libraries that use a mixture of H98 and more modern modules to move towards the more modern story.

11 11

Reducing the cost of garbage collecting small arrays
by Johan Tibell 24 Jun '11

24 Jun '11

Hi, Now when we can efficiently copy small arrays I've gone back to benchmarking/optimizing my hash array mapped trie data structure. The data structure's performance depends on how efficiently we can allocate/collect/copy Array#s and MutableArrays#s of size <=32. Speeding up copying helped quite a bit, but the HAMT is still slower than a Patricia tree for inserts. If you look at the data below you can see that GC time totally dominates the runtime. Is there anything that can be done to make the GC cheaper in this case? If I'm reading the output below right it's not allocating the space that takes most of the time, but later evacuating/scavenging it. Benchmark ========= {-# LANGUAGE BangPatterns #-} module Main (main) where import Data.List import qualified Data.HashMap as HM test :: HM.HashMap Int Int -> Int -> HM.HashMap Int Int test !m 0 = m test m n = test (HM.insert n n m) (n-1) {-# NOINLINE test #-} main = print $ HM.null $ test HM.empty 1000000 Hash array mapped trie ====================== $ time perf record -f ./test False [ perf record: Woken up 13 times to write data ] [ perf record: Captured and wrote 1.672 MB perf.data (~73041 samples) ] real 0m2.562s user 0m0.020s sys 0m0.010s # Samples: 72980 # # Overhead Command Shared Object Symbol # ........ ............... .......................... ...... # 52.79% test ./test [.] evacuate 9.49% test ./test [.] 0x000000000b4544 8.47% test ./test [.] scavenge_block 6.27% test ./test [.] s4UJ_info 4.67% test ./test [.] s1Od_info 4.22% test ./test [.] scavenge_mut_arr_ptrs 3.68% test ./test [.] s4N7_info 0.72% test ./test [.] todo_block_full 0.55% test ./test [.] GarbageCollect 0.55% test ./test [.] freeGroup Patricia tree ============= $ time perf record -f ./test False [ perf record: Woken up 11 times to write data ] [ perf record: Captured and wrote 1.292 MB perf.data (~56470 samples) ] real 0m1.984s user 0m0.020s sys 0m0.010s # Samples: 56409 # # Overhead Command Shared Object Symbol # ........ ............... .................... ...... # 49.30% test ./test [.] evacuate 24.75% test ./test [.] sa4B_info 14.56% test ./test [.] scavenge_block 1.31% test ./test [.] sa4k_info 1.25% test ./test [.] sa4m_info 1.25% test ./test [.] 0x00000000004108 0.72% test [kernel] [k] clear_page_c 0.66% test ./test [.] todo_block_full 0.46% test [kernel] [k] page_fault 0.44% test ./test [.] GarbageCollect P.S. I also need to figure out what 0x000000000b4544 corresponds to in the first perf events report. I thought my fix to the generated assembly files should have taken care of the unknown symbol problem. Cheers, Johan

3 6

Superclass equalities
by Simon Peyton-Jones 23 Jun '11

23 Jun '11

Friends I have long advertised a plan to allow so-called superclass equalities. I've just pushed patches to implement them. So now you can write class (F a ~ b) => C a b where { ... } This email is just to encourage you to try them out. Currently this is just in the HEAD git repository. It'll appear in GHC 7.2, a release we are now actively preparing. But the feature isn't heavily tested (since it didn't exist until today), so I'd appreciate people trying it out. Thanks Simon

3 2

Re: [GHC] #5051: Typechecker behaviour change
by Serge D. Mechveliani 23 Jun '11

23 Jun '11

Simon, thank you. Currently, DoCon works under ghc-7.0.1. And as I understand, the next release which is going to support DoCon (with its heavy use of overlapping instances) will be ghc-7.2. Regards, -------- Serge Mechveliani, mechvel(a)botik.ru On Wed, Jun 22, 2011 at 11:01:53AM -0000, GHC wrote: > #5051: Typechecker behaviour change > ---------------------------+------------------------------------------------ > Reporter: igloo | Owner: simonpj > Type: bug | Status: closed > Priority: high | Milestone: 7.2.1 > Component: Compiler | Version: 7.0.2 > Resolution: fixed | Keywords: > > [..] > > GHC 7 indeed falls over on `DoCon` 2.12. It turns out to be a rather > subtle interaction of overlapping instances with the ill-fated "silent > superclass parameters" I introduced to solve a problem in the > typechecker's constraint solver. > [..]

2 1

Type function under a forall type
by Stefan Holdermans 23 Jun '11

23 Jun '11

Simon, Tom, I hit this type-error message in GHC 7.0.3: Cannot deal with a type function under a forall type: forall e. El e u Is there a fundamental reason why type functions under a forall type are a bad idea? Of is it just something that hasn't been implemented/thought about yet? Cheers, Stefan

2 1

ANNOUNCE: GHC version 7.0.4
by Ian Lynagh 22 Jun '11

22 Jun '11

============================================================= The (Interactive) Glasgow Haskell Compiler -- version 7.0.4 ============================================================= The GHC Team is pleased to announce a new patchlevel release of GHC. This release contains a handful of bugfixes relative to 7.0.3, so we recommend upgrading. The release notes are here: http://www.haskell.org/ghc/docs/7.0.4/html/users_guide/release-7-0-4.html How to get it ~~~~~~~~~~~~~ The easy way is to go to the web page, which should be self-explanatory: http://www.haskell.org/ghc/ We supply binary builds in the native package format for many platforms, and the source distribution is available from the same place. Packages will appear as they are built - if the package for your system isn't available yet, please try again later. Background ~~~~~~~~~~ Haskell is a standard lazy functional programming language. GHC is a state-of-the-art programming suite for Haskell. Included is an optimising compiler generating good code for a variety of platforms, together with an interactive system for convenient, quick development. The distribution includes space and time profiling facilities, a large collection of libraries, and support for various language extensions, including concurrency, exceptions, and foreign language interfaces (C, whatever). GHC is distributed under a BSD-style open source license. A wide variety of Haskell related resources (tutorials, libraries, specifications, documentation, compilers, interpreters, references, contact information, links to research groups) are available from the Haskell home page (see below). On-line GHC-related resources ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relevant URLs on the World-Wide Web: GHC home page http://www.haskell.org/ghc/ GHC developers' home page http://hackage.haskell.org/trac/ghc/ Haskell home page http://www.haskell.org/ Supported Platforms ~~~~~~~~~~~~~~~~~~~ The list of platforms we support, and the people responsible for them, is here: http://hackage.haskell.org/trac/ghc/wiki/Contributors Ports to other platforms are possible with varying degrees of difficulty. The Building Guide describes how to go about porting to a new platform: http://hackage.haskell.org/trac/ghc/wiki/Building Developers ~~~~~~~~~~ We welcome new contributors. Instructions on accessing our source code repository, and getting started with hacking on GHC, are available from the GHC's developer's site run by Trac: http://hackage.haskell.org/trac/ghc/ Mailing lists ~~~~~~~~~~~~~ We run mailing lists for GHC users and bug reports; to subscribe, use the web interfaces at http://www.haskell.org/mailman/listinfo/glasgow-haskell-users http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs There are several other haskell and ghc-related mailing lists on www.haskell.org; for the full list, see http://www.haskell.org/mailman/listinfo/ Some GHC developers hang out on #haskell on IRC, too: http://www.haskell.org/haskellwiki/IRC_channel Please report bugs using our bug tracking system. Instructions on reporting bugs can be found here: http://www.haskell.org/ghc/reportabug

2 1

Re: GHC and Haskell 98
by John Lato 20 Jun '11

20 Jun '11

> > From: Bas van Dijk <v.dijk.bas(a)gmail.com> > > On 17 June 2011 16:47, Simon Peyton-Jones <simonpj(a)microsoft.com> wrote: > > So: ? ?Under Plan A, some Hackage packages will become un-compilable, > > ? ? ? and will require source code changes to fix them. ?I do not have > > ? ? ? ?any idea how many Hackage packages would fail in this way. > > Of the 372 direct reverse dependencies of haskell98: > > > http://bifunctor.homelinux.net/~roel/cgi-bin/hackage-scripts/revdeps/haskel… > > there are 344 which also depend on base (See http://hpaste.org/47933 > for calculating the intersection). > Is it easy to check, out of those 344, how many would build if the dependency on haskell98 were removed? I suspect it's not needed for the majority of cases. +1 for Plan A, but interested in mitigating the negative consequences. (Bas, your link doesn't work for me BTW, can't resolve the IP. May be my uni's dns cache.) John Lato

3 2

MonoLocalBinds and hoopl
by Edward Z. Yang 19 Jun '11

19 Jun '11

Hello all, Here's an experience report for porting hoopl to manage MonoLocalBinds. The Compiler.Hoop.XUtil module has a rather interesting (but probably common) style of code writing, along the lines of this: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock f m l cat) block where f n = FF3 $ ff n m n = FF3 $ fm n l n = FF3 $ fl n FF3 f `cat` FF3 f' = FF3 $ f' . f f, m, l and cat are polymorphic functions that are only used once in the main expression, and are floated outside to improve readability. However, when MonoLocalBinds is turned on, these all become monomorphic and the definitions fail. In contrast, this (uglier) version typechecks: fbnf3 (ff, fm, fl) block = unFF3 $ scottFoldBlock (ScottBlock (FF3 . ff) (FF3 . fm) (FF3 . fl) (\(FF3 f) (FF3 f') -> FF3 $ f' . f)) block One suggestion that I had was that we should generalize local bindings that are only used once, but Marlow pointed out that this would make the typechecker more complex and I probably would agree. As a userspace developer, I have two options: 1. Bite the bullet and put in the polymorphic type signatures (which can be quite hefty) 2. Inline the definitions 3. Move the polymorphic functions into the global namespace (3) and (2) are not so nice because it breaks the nice symmetry between these definitions, which always define f, m, l for the many, many definitions in Hoopl of this style. Cheers, Edward

6 8

ghc cyclic import error confusing
by Evan Laforge 16 Jun '11

16 Jun '11

I've found ghc's cyclic import error to be rather confusing, and I finally took the time to understand why. Here's an example: Module imports form a cycle for modules: Cmd.Cmd (./Cmd/Cmd.hs) imports: Perform.Midi.Instrument Instrument.MidiDb Instrument.Db Perform.Midi.Instrument (./Perform/Midi/Instrument.hs) imports: Cmd.Cmd Instrument.MidiDb (./Instrument/MidiDb.hs) imports: Perform.Midi.Instrument Instrument.Db (./Instrument/Db.hs) imports: Instrument.Search Instrument.MidiDb Perform.Midi.Instrument Instrument.Search (./Instrument/Search.hs) imports: Instrument.MidiDb Perform.Midi.Instrument It seems to be in a strange order and mentions extraneous modules. I would find this much easier to read: Perform.Midi.Instrument -> Cmd.Cmd -> Instrument.MidiDb -> Perform.Midi.Instrument Instead, the order goes Cmd.Cmd -> Instrument.MidiDb, and then goes backwards to Perform.Midi.Instrument -> Cmd.Cmd. Then it goes forward again to Instrument.MidiDb -> Perform.Midi.Instrument. So the order makes you jump around if you want to trace the import chain. The duplicated module that joins the cycle is not visually highlighted. Whats more, it further confuses the eye by merging in multiple loops. I suppose it could be useful to include additional loops, but I would find it easier to read if they were included on their own line, such as: Cmd.Cmd -> Instrument.Db -> Instrument.Search -> Perform.Midi.Instrument -> Cmd.Cmd However, I think probably the shortest loop is the most interesting one, and if there are multiple shortest loops, simply picking one randomly is likely to be sufficient. Thoughts?

5 5

URL for GHC 7.0.3
by Simon Sin 16 Jun '11

16 Jun '11

hi, GHC freaks, I tried to set up GHCi 7.0.3 and the latest haskell-platform on my new buntu 11.04 installation. I can successfully did it for 6.10.3 by following the instruction from one web post (Spork Code). Then I following the URL given by another web post to 'wget' the 7.0.3. but get an error 404 file not found. Can anybody point me to the correct URL to get 7.0.3 tar.bz2 ? Thank you very much. Simon.

3 3