December 2009 - Glasgow-haskell-users

partially applied type synonyms
by Arie Peterson 05 Mar '12

05 Mar '12

Dear list, Is there a good reason that partially applied type synonyms cannot be made instances of classes? - A simple example would be making the identity type 'Id' ("type Id x = x") instance of 'Monad'. This would eliminate the need for some silly occurrences of 'runIdentity', and perhaps narrow the gap between monads and monad transformers. - The reason I complain about this now is a more involved example, where introducing a newtype to work around the restriction is not an option. Well, not as far as I can see now, anyway. Partially applied type synonyms are, in a sense, the anonymous functions at the type level, and one might argue that they deserve the same 'first-class member status' as the lambda at the value level. Kind regards, Arie Peterson

3 2

Update on GHC 6.12.1
by Simon Peyton-Jones 09 Feb '10

09 Feb '10

Folks This is an update on the status of GHC 6.12. FIRST, as you probably know, Hackage and the Haskell Platform is allowing GHC HQ to get out of the libraries business. So the plan is - We release GHC 6.12 with very few libraries - Bill Library Author downloads GHC 6.12 and tests his libraries - The next Haskell Platform release packages GHC 6.12 with these tested libraries - Joe User downloads the Haskell Platform. - Four months later there's a new HP release, still with GHC 6.12, but with more or better libraries. The HP release cycle is decoupled from GHC So if you are Joe User, you want to wait for the HP release. Don't grab the GHC 6.12 release. It'll be perfectly usable, but only if you use (an up to date) cabal-install to download libraries, and accept that they may not be tested with GHC 6.12. SECOND, we have produced Release Candidate 1 for GHC 6.12.1, and are about to produce RC2. However, before releasing 6.12 we'd like to compile all of Hackage, in case doing so reveals bugs in GHC's APIs (which are not supposed to change). But we can't do that until an update to cabal-install is ready. (We don't expect this dependency to happen all the time, but it does hold for 6.12.) Duncan has been working on the cabal-install update, and expects to release by end November. So the timetable looks like this: - Very soon: GHC 6.12.1 release candidate 2 - End Nov: cabal-install release - ...test GHC against Hackage... - Early Dec: release GHC 6.12 - ...library authors and HP folk get busy... - End Jan (?): Haskell Platform release - ...Joe User downloads HP... FINALLY, below I summarise a late change that's been pending for a long time, which I propose to sneak into RC2, for reasons explained below. If you can see a good reason not to do this, yell. Simon Recursive do-notation. ~~~~~~~~~~~~~~~~~~~~~~ The change is this. Instead of writing mdo { a <- getChar ; b <- f c ; c <- g b ; putChar c ; return b } you would write do { a <- getChar ; rec { b <- f c ; c <- g b } ; putChar c ; return b } That is, * 'mdo' is eliminated * 'rec' is added, which groups a bunch of statements into a single recursive statement See http://hackage.haskell.org/trac/ghc/ticket/2798 This 'rec' thing is already present for the arrow notation, so it makes the two more uniform. Moreover, 'rec' lets you say more precisely where the recursion is (if you want to), whereas 'mdo' just says "there's recursion here somewhere". Lastly, all this works with rebindable syntax (which mdo does not). Currently 'mdo' is enabled by -XRecursiveDo. So we propose to deprecate this flag, with another flag -XDoRec to enable the 'rec' keyword. The main question is not whether to make this change, but when. I'm inclined to do put it into GHC 6.12, even though it's late in the day because then we can take mdo out of 6.14 altogether. Another minor question is whether "-XDoRec" is a good name for the flag. We can't really use "-XRecursiveDo" because that's the one we are deprecating!

12 18

Building GHC 6.12 with GHC 6.12 + alex
by Antoine Latter 05 Jan '10

05 Jan '10

Folks, I've run into trouble building GHC 6.12 with alex built from GHC 6.12: "/Users/alatter/usr/bin/alex" -g compiler/parser/Lexer.x -o compiler/stage1/build/Lexer.hs alex: compiler/parser/Lexer.x: hGetContents: invalid argument (Illegal byte sequence) however things like: ghci> readFile "compiler/parser/Lexer.x" apear to work just fine. Has anyone else seen this? Has anyone else succeeded in this? This is on Mac OS X 10.6, running on Intel Core 2 Duo. I'm trying to compile a recent pull of the 6.12 branch. Thanks, Antoine

2 5

Where did the GHC API go?
by Jason Dusek 05 Jan '10

05 Jan '10

Maybe I missed an email about this... http://www.haskell.org/ghc/docs/latest/html/libraries/ghc/index.html The link is down. -- Jason Dusek

9 19

GHC.Prim.ByteArray# - confusing documentation
by Antoine Latter 02 Jan '10

02 Jan '10

Folks, I found some of the documentation in GHC.Prim confusing - so I thought I'd share. The documentation for the ByteArray# type[1] explains that's it's a raw region in memory that also remembers it's size. Consequently I expected sizeOfByteArray# to return the same number that I passed in to newByteArray#. But it doesn't - It returned however much it decided to allocate, which on my platform is always a multiple of four bytes. This is something which could be clarified in the documentation. So it turns out I need to carry my own length around in something like (Int, ByteArray#). (I tested all of this with the primitive[2] package, which is a thin wrapper around GHC.Prim) Antoine 1: http://hackage.haskell.org/packages/archive/ghc-prim/0.1.0.0/doc/html/GHC-P… 2: http://hackage.haskell.org/package/primitive

4 6

Re: Re: ANN: Happstack 0.4.1
by Antoine Latter 02 Jan '10

02 Jan '10

On Mon, Dec 21, 2009 at 6:31 AM, <jeremy(a)n-heptane.com> wrote: > Hello, > > That sort of missing symbol error at link time is often (but not always) a > sign that some libraries got recompiled but not others. So there are > references to the old symbol names hanging around. > > I would try to ghc-pkg unregister syb-with-class and everything that depends > on it, and then try cabal install happstack again. > I'm pretty well stumped at this point. I've cleared off everything and gone up to GHC 6.12 HEAD, and a 'cabal install happstack-data' gives me the same symbol not defined error in Happstack.Data.Xml.Base. But here's the spooky part, if I run it by hand like so: ghc --make src/Happstack/Data/Xml/Base.hs src/Happstack/Data/Default.hs src/Happstack/Data/ DeriveAll.hs src/Happstack/Data/Normalize.hs src/Happstack/Data/Migrate.hs after resolving issues due to CPP not being run, everything runs to completion, no errors. Also, the list of things we're pulling in during the template-haskell execution is much smaller (see bellow). Has anyone seen this, where template-haskell behaves different when run from cabal-install (or Setup.hs) than from ghc --make (or ghci)? >>>>> 2 of 5] Compiling Happstack.Data.Migrate ( src/Happstack/Data/Migrate.hs, src/Happstack/Data/Migrate.o ) [3 of 5] Compiling Happstack.Data.Default ( src/Happstack/Data/Default.hs, src/Happstack/Data/Default.o ) [4 of 5] Compiling Happstack.Data.DeriveAll ( src/Happstack/Data/DeriveAll.hs, src/Happstack/Data/DeriveAll.o ) [5 of 5] Compiling Happstack.Data.Xml.Base ( src/Happstack/Data/Xml/Base.hs, src/Happstack/Data/Xml/Base.o ) Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading package ffi-1.0 ... linking ... done. Loading package array-0.3.0.0 ... linking ... done. Loading package bytestring-0.9.1.5 ... linking ... done. Loading package containers-0.3.0.0 ... linking ... done. Loading package pretty-1.0.1.1 ... linking ... done. Loading package syb-0.1.0.2 ... linking ... done. Loading package template-haskell ... linking ... done. Loading package syb-with-class-0.6.1 ... linking ... done. mkUsageInfo: internal name? Element{tc a4av} <<<<< That was the successful build, using ghc --make. The error for te failing build is quoted bellow. Antoine > > > > On Sun 12/20/2009 2:06 AM , Antoine Latter aslatter(a)gmail.com sent: > > 2009/12/19 Jeremy Shaw <jeremy(a)n-heptane.com>: >> Happstack 0.4.1 STABLE is now available. > > At some point I was able to get happstack to build on GHC 6.12, but now I > can't. > > I'm getting errors in happstack-data, specifically it looks like > errors when I'm running TemplateHaskell during compile-time: > >>>>>> > [ 7 of 16] Compiling Happstack.Data.Xml.Base ( > src/Happstack/Data/Xml/Base.hs, dist/build/Happstack/Data/Xml/Base.o ) > Loading package ghc-prim ... linking ... done. > Loading package integer-gmp ... linking ... done. > Loading package base ... linking ... done. > Loading package array-0.3.0.0 ... linking ... done. > Loading package bytestring-0.9.1.5 ... linking ... done. > Loading package containers-0.3.0.0 ... linking ... done. > Loading package pretty-1.0.1.1 ... linking ... done. > Loading package template-haskell ... linking ... done. > Loading package syb-with-class-0.6.1 ... linking ... done. > Loading package HUnit-1.2.2.1 ... linking ... done. > Loading package syb-0.1.0.2 ... linking ... done. > Loading package base-3.0.3.2 ... linking ... done. > Loading package old-locale-1.0.0.2 ... linking ... done. > Loading package time-1.1.4 ... linking ... done. > Loading package random-1.0.0.2 ... linking ... done. > Loading package QuickCheck-1.2.0.0 ... linking ... done. > Loading package extensible-exceptions-0.1.1.1 ... linking ... done. > Loading package mtl-1.1.0.2 ... linking ... done. > Loading package old-time-1.0.0.3 ... linking ... done. > Loading package parsec-2.1.0.1 ... linking ... done. > Loading package hsemail-1.3 ... linking ... done. > Loading package network-2.2.1.5 ... linking ... done. > Loading package SMTPClient-1.0.1 ... linking ... done. > Loading package filepath-1.1.0.3 ... linking ... done. > Loading package unix-2.4.0.0 ... linking ... done. > Loading package directory-1.0.1.0 ... linking ... done. > Loading package process-1.0.1.2 ... linking ... done. > Loading package hslogger-1.0.7 ... linking ... done. > Loading package deepseq-1.1.0.0 ... linking ... done. > Loading package parallel-2.2.0.1 ... linking ... done. > Loading package strict-concurrency-0.2.2 ... linking ... done. > Loading package unix-compat-0.1.2.1 ... linking ... done. > Loading package happstack-util-0.4.1 ... linking ... done. > Loading package binary-0.5.0.2 ... linking ... done. > Loading package haskell98 ... linking ... done. > Loading package HaXml-1.13.3 ... linking ... done. > Loading package ffi-1.0 ... linking ... done. > ghc: > unknown symbol > `_sybzmwithzmclasszm0zi6zi1_DataziGenericsziSYBziWithClassziInstances_dataTypeZMad6eZN_closure' > <<<<< > > If you check the load-list, we are loading syb-with-class. > > This is on Mac OS X 10.6 on a 64-bit intel chip, if that makes any > difference. > > Has anyone seen anything like this? Is it likely I've screwed up my > GHC install somehow? > > Antoine > > -- > > You received this message because you are subscribed to the Google Groups > "HAppS" group. > To post to this group, send email to happs(a)googlegroups.com. > To unsubscribe from this group, send email to > happs%2Bunsubscribe(a)googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/happs?hl=en. > > > >

3 2

GHC-6.12.1: broken configure
by Kirill A. Shutemov 30 Dec '09

30 Dec '09

I want to build ghc for i586-alt-linux-gnu. > ./configure --host=i586-alt-linux-gnu --build=i586-alt-linux-gnu checking for gfind... no checking for find... /bin/find checking for sort... /bin/sort checking for ghc... /usr/bin/ghc checking version of ghc... 6.10.1 Target platform inferred as: i386-unknown-linux Unknown arch i586 Why i586 is unknown? It's a valid architecture. Why does it check vendor? Many of distribution define own vendor. Why do not use config.guess to guess correct host/target/build instead of reinvent wheel? Please fix it. It will simplify packaging GHC for distributions.

5 5

Re: [Haskell-beginners] Performance of parallel mergesort
by Yitzchak Gale 30 Dec '09

30 Dec '09

This discussion definitely does not belong on the Haskell-Beginners list. Besides not being a topic for beginners, being there is keeping it under the radar of many or most of the people who work on these things in Haskell. I am moving the discussion to the GHC users list, as suggested by Antoine. For those joining us in progress, the first part of the thread starts here: http://www.haskell.org/pipermail/beginners/2009-December/003045.html On Mon, Dec 28, 2009 at 5:19 AM, Jon Harrop wrote: > On Sunday 27 December 2009 20:56:51 Stephen Blackheath wrote: >> Jon Harrop wrote: >> > This is something that concerns me. Lots of discussions of parallelism, >> > including the Haskell literature I have read, neglect this critical >> > problem >> > of making sure that more time is spent doing useful work than spawning >> > tasks >> > (sparks). How is this solved in Haskell? Do you just put magic numbers in >> > that work on the machine you're currently using? >> >> It is simply not true that Haskell literature neglects the question of >> spark granularity - this is very basic and is always covered. Read >> "Real World Haskell" (available free online). There's no 'magic >> number'. You must explicitly write your code to give the right granule >> size. > > There is no "right granule" size. That's the whole point: the optimum is a > function of the machine. If you hardcode the granularity then your code isn't > future proof and isn't portable. > > From chapter 24 of Real World Haskell on sorting: > > "At this fine granularity, the cost of using par outweighs any possible > usefulness. To reduce this effect, we switch to our non-parallel sort after > passing some threshold." > > From the Sorting.hs file, parSort2 accepts a threshold "d": > > parSort2 :: (Ord a) => Int -> [a] -> [a] > parSort2 d list@(x:xs) > | d <= 0 = sort list > | otherwise = force greater `par` (force lesser `pseq` > (lesser ++ x:greater)) > where lesser = parSort2 d' [y | y <- xs, y < x] > greater = parSort2 d' [y | y <- xs, y >= x] > d' = d - 1 > parSort2 _ _ = [] > > From the SortMain.hs file, it is always invoked with the magic number "2": > > testFunction = parSort2 2 > > Moreover, their approach of subdividing a fixed number of times is suboptimal > because it inhibits load balancing. > > Later, about parallelized IO, they give the code: > > chunkedReadWith :: (NFData a) => > ([LB.ByteString] -> a) -> FilePath -> IO a > chunkedReadWith func path = > withChunks (lineChunks (numCapabilities * 4)) func path > > where "4" is one magic number that gets multiplied by the magic number the > user supplied via the +RTS -N<n> command-line option. > > They make no attempt to adapt the granularity to the machine at all and rely > entirely upon magic numbers. Consequently, their parallel sort that got a 25% > speedup on two cores achieves a 30% slowdown on my 8 core. > >> I don't know the exact cost of sparking, but in my experience it >> is quite small - so - as long as your granule is doing *some* real work, >> it should speed up. > > Can you quantify it, e.g. How many FLOPS? > >> Jon Harrop wrote: >> > The parallelism is obviously not obtaining any real speedup so something >> > is wrong. But can anyone fix it? >> >> I've spent a bit of time measuring parallel speedup on real commercial >> projects, and this is what I've found: >> >> 1. ghc-6.12 performs significantly better than ghc-6.10, and has now >> been released, therefore don't use ghc-6.10. > > Ok. > >> 2. The defaults generally work better than giving huge heap sizes. Your >> -K100000000 - maximum heap size per thread - will either do nothing or >> cause an artificial slowdown (I have observed this with the minimum heap >> size option). Don't use it, unless experimentation proves it makes >> things better. > > On the contrary, the Haskell program dies without it: > > $ time ./mergesort +RTS -N8 > Stack space overflow: current size 8388608 bytes. > Use `+RTS -Ksize' to increase it. > [1]+ Done kwrite mergesort.hs > > real 0m33.320s > user 3m29.397s > sys 0m0.592s > > I had to add that -K command line option just to get the program to run to > completion. > >> 3. +RTS -s is well worth using. It breaks the time down into MUT >> (mutator) and GC (garbage collector). > > Its says 78.5% GC time (with GHC 6.10). > >> 4. MUT parallelization is excellent, but the parallel GC is not so good. >> If your code is GC-heavy it can spend around half of its time garbage >> collecting, which doesn't parallelize so well, and this eats into the >> speedup. > > Ok. > >> 5. There seems to be a scalability problem with the parallel gc for >> larger numbers of cores (namely 8). I am guessing somewhat, but my >> experiments tend to confirm the issue raised in Simon Marlow's (the >> implementor of GHC parallelization) recent paper that it's to do with >> "stopping the world" for gc. > > Do you mean this bug: > > http://hackage.haskell.org/trac/ghc/ticket/3553 > >> If GHC's lack of perfection at this point in time makes Haskell "look >> bad" I don't mind. I am not selling anything, so the reader at least >> knows they're getting the truth. I see this as one of the great >> advantages of open source. > > I'm sure we'd all rather see speedups. :-) > >> Progress on GHC has been very rapid in the last couple of years, and so >> I know we'll continue to see the speed of GHC's parallelism improving in >> leaps and bounds. It's actually still quite a new area, considering the >> difficulty of some of the technical issues and how recent it is that >> multicores are widely available on consumer hardware. > > My original intent was to test a claim someone made: that mergesort in Haskell > is competitively performant and trivially parallelized. > >> I know you OCaml/F# guys are making great progress too. > > F# is production ready but OCaml is dead in the water when it comes to > multicore. I'm working on an OCaml replacement called HLVM but it is early > days yet. > > -- > Dr Jon Harrop, Flying Frog Consultancy Ltd. > http://www.ffconsultancy.com/?e > _______________________________________________ > Beginners mailing list > Beginners(a)haskell.org > http://www.haskell.org/mailman/listinfo/beginners >

4 4

hsc2hs and base
by Bryan O'Sullivan 30 Dec '09

30 Dec '09

Hi, Simon — Is it licit to have source files in base depend on preprocessing by hsc2hs? My suspicion is "no", but I want to be sure. Thanks, Bryan.

3 3

Qualified names in import lists
by Niklas Broberg 29 Dec '09

29 Dec '09

Hi all, I have a bug report [1] for haskell-src-exts pertaining to the use of qualified names in import specifications, e.g. module Main where import Foo (Bar.bar) GHC apparently accepts this code, but I can find no mention of such a feature in the GHC docs. Personally I don't see why this should be allowed at all, as it breaks the abstraction layer w.r.t. re-exporting names from other, possibly internal, modules. If there's some reasonable use for it, it should at the very least be tied to a documented and registered extension. I've submitted a ticket for GHC [2] to either remove this feature, or properly document it. I'd be curious to hear what the reasoning behind it is, if any. Cheers, /Niklas ps. Why is there no "GHC accepts invalid program" option for "Type of failure"? Too few cases? I set this ticket to Other. [1] http://trac.haskell.org/haskell-src-exts/ticket/57 [2] http://hackage.haskell.org/trac/ghc/ticket/3792

2 2