- Glasgow-haskell-users

How MD are .hi files?
by Matthias Kilian 15 May '08

15 May '08

Hi, for an unregisterised ghc-6.8.2 (or newer), are the .hi files dependent (except for the 32 vs. 64 bit word size)? I had a quick look at the stuff in compiler/iface, but the only MD part I found was that 32/64 bit difference. TIA Ciao, Kili ps: if you think this sounds like a complete newbie question, you're right; I've been far too busy hacking on boring stuff like Makefiles, and didn't have time to look at the interesting code (i.e. ghc itself). My knowledge of ghc's internals is at the state of 1998, or even older, I really don't remember ;-) -- Options are good. As long as they are optional. -- Artur Grabowski

2 3

Performance: Faster to define a function writing out all arguments?
by Alexander Fuchs 14 May '08

14 May '08

Hi there, I am trying to write my first serious Haskell program, but have problems understanding 'strange' performance results. It seems to be a ghc specific question, so I am asking here. In a happy parser I have this code 1): %monad { Parsed } { thenP } { returnP } type Parsed = State Env.Env returnP :: a -> Parsed a returnP a = return a thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP x k = x >>= k An alternative was this 2) (yes, redundant in happy): returnP :: a -> Parsed a returnP = return thenP :: Parsed a -> (a -> Parsed b) -> Parsed b thenP = (>>=) And strangely enough on my machine 1) is faster by a few percent than 2) using ghc 6.8.2 with -O2. A few percent might seem unimportant, but I am currently developing my Haskell style. And I want to write efficient code by default, if that doesn't lead to obfuscation. Now, first I dislike using option 1) because it seems pointlessly verbose. Second, I have no clue why option 2) should be faster. Using ghc -O2 -C I get two code blocks with 1) (appended at the end of this mail), whereas I get nothing with 2. Unfortunately, that doesn't help me as I have no clue what it means. There are also various strictness annotations throughout the code to make parsing less memory hungry (and getting an intuition about what is appropriate here drives me crazy). Random guess: perhaps somehow strictness analysis of ghc benefits from the code in 1)? Or does ghc create specialized versions of return and >>= for State instantiated to Parsed, i.e. State Env.Env? Anyhow, I am puzzled and grateful for any explanations and recommendations about what is going on and when to avoid style 2). Thanks, Alexander C-- code blocks: ------------------------------------------------------- EI_(DarwinziTptpziParser_a106_info); StgWord DarwinziTptpziParser_a106_closure[] = { (W_)&DarwinziTptpziParser_a106_info }; static StgWord s8Ey_info[] = { 0x42U, 0x22U }; IF_(s8Ey_ret) { W_ _c8EL; FB_ Sp[2] = *((P_)(R1.w+7)); _c8EL = *((P_)(R1.w+3)); R1.w = Sp[1]; Sp[1] = _c8EL; Sp=Sp+1; JMP_((W_)&stg_ap_pp_fast); FE_ } StgWord DarwinziTptpziParser_a106_info[] = { 0x30014U, 0x0, 0xfU }; EI_(DarwinziTptpziParser_a106_closure); II_(s8Ey_info); FN_(DarwinziTptpziParser_a106_entry) { FB_ if ((W_)(((W_)Sp - 0x4U) < (W_)SpLim)) goto _c8EO; R1.w = *Sp; Sp[-1] = Sp[2]; *Sp = (W_)&s8Ey_info; Sp=Sp-1; JMP_((W_)&stg_ap_p_fast); _c8EO: R1.w = (W_)&DarwinziTptpziParser_a106_closure; JMP_(stg_gc_fun); FE_ } ------------------------------------------------------- ------------------------------------------------------- II_(r6AT_info); static StgWord r6AT_closure[] = { (W_)&r6AT_info, 0x0, 0x0, 0x0 }; static char c97W_str[] = "Internal Happy error\012"; static StgWord r6AT_info[] = { 0x0, 0x16U }; EI_(base_GHCziBase_unpackCStringzh_info); IF_(r6AT_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c97Z; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c97Z; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; Sp[-3] = (W_)&c97W_str; Sp=Sp-3; JMP_((W_)&base_GHCziBase_unpackCStringzh_info); _c97Z: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } EI_(base_GHCziErr_error_closure); II_(r6AT_closure); StgWord DarwinziTptpziParser_notHappyAtAll_srt[] = { (W_)&base_GHCziErr_error_closure, (W_)&r6AT_closure }; EI_(DarwinziTptpziParser_notHappyAtAll_info); StgWord DarwinziTptpziParser_notHappyAtAll_closure[] = { (W_)&DarwinziTptpziParser_notHappyAtAll_info, 0x0, 0x0, 0x0 }; StgWord DarwinziTptpziParser_notHappyAtAll_info[] = { ((W_)&DarwinziTptpziParser_notHappyAtAll_srt+0), 0x0, 0x30016U }; EI_(base_GHCziErr_error_closure); II_(r6AT_closure); FN_(DarwinziTptpziParser_notHappyAtAll_entry) { FB_ if ((W_)(((W_)Sp - 0xcU) < (W_)SpLim)) goto _c989; Hp=Hp+2; if ((W_)((W_)Hp > (W_)HpLim)) goto _c989; Hp[-1] = (W_)&stg_CAF_BLACKHOLE_info; newCAF((void *)R1.w); R1.p[1] = (W_)Hp-4; *R1.p = (W_)&stg_IND_STATIC_info; Sp[-2] = (W_)&stg_upd_frame_info; Sp[-1] = (W_)Hp-4; R1.w = (W_)&base_GHCziErr_error_closure; Sp[-3] = (W_)&r6AT_closure; Sp=Sp-3; JMP_((W_)&stg_ap_p_fast); _c989: HpAlloc = 0x8U; JMP_(stg_gc_enter_1); FE_ } -------------------------------------------------------

4 6

small and compact ghc distribution
by leledumbo 14 May '08

14 May '08

Currently, GHC distribution is VERY BIG (about 410 MB). 2 Things that I noticed which contributed most of this problem are: libraries (about 220 MB) and GCC and friends compiler (including perl, ar, as, ld, etc). I'm a college student and I just want to learn functional programming with Haskell. No need to access libraries other than GHC rtl (or whatever you call it). I already have gcc on my machine, does GHC still need its own? Will there be any small and compact GHC distribution (if someone wants to make it, I'd be very grateful)? -- View this message in context: http://www.nabble.com/small-and-compact-ghc-distribution-tp17223701p1722370… Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.

2 2

ANN: ghc 6.8.2 from MacPorts
by Gregory Wright 06 May '08

06 May '08

After what many would consider an unconscionable delay, I am happy to announce that ghc 6.8.2 is available from MacPorts. The ghc 6.8.2 port is available for Tiger/ppc, Tiger/intel and Leopard/ intel. Users with Leopard/ppc are out of luck until for now, for reason discussed earlier on this list. In partial recompense for their patience, users will get a ghc with more patches than any previous MacPorts ghc. A few notes: The file locking bugs #1992 and #2134 are fixed. Bug #1992 was a simple lock logic error and should be killed dead. Bug #2134 was the result of a lazy readFile holding a lock for an unpredictable time. There may be more cases like this one, and I would appreciate a note from anyone who come across a lock error during building. Users on Leopard/intel must upgrade to 10.5.2 to avoid an OS bug which under unusual circumstances would repeatably (and mysteriously) crash the build. This was first noticed running the building in an eshell under Aquamacs. Archives were built without tables of contents because ranlib wasn't being run or wasn't running to completion. Builds in the usual Terminal.app didn't trip over this bug. OpenGL support is built by default. It can be turned off using the no_opengl variant. OpenAL support is disabled. Apple's OpenAL framework lacks ALUT support (needed for the ghc binding) but has name clashes with the freealut library from the OpenAL.org website. Fixing this is probably straightforward. If someone is interested, I can give them some pointers on getting started. MacPort's ghc ought to always link with the correct libgmp (the one provided by the gmp port). The latest versions of alex, happy, haddock and hs-Edison are also available. Best Wishes, Greg

10 20

Warnings about unused variables or imports
by Simon Peyton-Jones 06 May '08

06 May '08

[Moving to GHC users: this thread concerns GHC's warning messages about unused things.] | But there are a few other inconvenient behaviors related only to | warnings, for instance | | module A where | foo x = x | | module B(foo) where | import A | | module C (module A, module B) where | import A | import B | | %> ghc --make C.hs -W: | | C.hs:1:20: Warning: `foo' is exported by `module B' and `module A' | | That's certainly true, but it's the same 'foo'. Just a warning of | course, and I'm not so sure I would argue that it shouldn't be there. | It's the same kind of warning as with any other multiple export of a | symbol I guess. But this pattern is not uncommon (in my code at | least), so the warning is inconvenient. Then again, that particular | warning can be turned off. Here the original intention was to warn about module C( foo, foo ) where... or perhaps module C( module A, foo ) where... but I agree that in the situation you describe the warning is silly. File a ticket for it? | Another, somewhat stranger, behavior: | | module A where | foo x = x | | module B(foo) where | import A | | module C(foo) where | import A | | module D () where | import B | import C | bar x = foo x | | %> ghc --make D.hs -W | | D.hs:2:0: | Warning: Module `B' is imported, but nothing from it is used, | except perhaps instances visible in `B' | To suppress this warning, use: import B() | | D.hs:3:0: | Warning: Module `C' is imported, but nothing from it is used, | except perhaps instances visible in `C' | To suppress this warning, use: import C() | | D.hs:4:0: Warning: Defined but not used: `bar' | | This might be said to be a bug, although it's a bug that would rarely | bite you, since it requires that 'bar' is not exported (or used in | something that is exported). If you export bar, then the warning talks | only of B - which is a rather arbitrary choice. There is something more substantial here. Suppose we have module Foo( g ) where import Bar( f4 ) f1 = f2 f2 = f3 f3 = f4 g = 7 At the moment GHC takes the view that f1,f2,f3,f4, and the import are *all* unused. If we said that just f1 was unused, then you'd delete it and get a new warning about f2; you delete that and get a new warning about f3; and so on. Yet the current behaviour is clearly confusing, even to a clued-up user, let alone a beginner. I'm starting to think that we should just do the obvious thing: report something as unused only if it physically does not occur. Any opinions? Your message also objects to arbitrarily choosing one of the imports as redundant. But if there are two imports import B import C and only one is needed, what would you like GHC to say? It's pretty hard to say "only one of these is needed", because it might be "of these three import declarations, you need 1&2 or 2&3 or 1&3". Simon

2 1

instance export decls
by Serge D. Mechveliani 03 May '08

03 May '08

Dear GHC developers, people, Do you agree that there exists such a problem for a programmer as recalling exported instances? Have Haskell and/or GHC some constructs and tools to help the programmer to recall the exported instances for a module? Could GHC support the instance export messages for each module? In Haskell-98, the exported instances cannot be named explicitly in the export list. Right? But for easier understanding of a program, it is desirable to allow to name (in a short form) instances in the export list. For this reason, I add comments, and write the export like this: module Poly (WithHead(..), WithTail(..), -- classes Mon(..), Polynomial(..), lc, polMons -- , instances -- for Mon: WithHead, List; -- for Polynomial: WithHead, Cast Polynomial Mon ) The comment of kind "-- , instances ..." helps to recall which instances are exported, without inspecting all the (lengthy) module source. But when the programmer changes the source, one often forgets to add/remove the needed comments about instances. I often forget them (maybe, lazy to recall) when I move pieces of code between modules. So, I suggest the following feature for GHC. 1. To allow the export declarations of kind instance {<type>} (maybe to suggest this for Haskell ?) 2. If the module under compilation has the word `instance' in its export list, then ghc finds the difference set diff for the exported instance kinds eKinds and the instance kinds nKinds named in the export list. If not $ null diff, it issues the message: "Warning: the exported instance kinds and the instance kinds named in the export differ in the following items: ...". Seeing such a message, the user corrects the export list in the source according to diff. For the export list and for their messages, it is probably better to use a short denotation: the instance kind rather than full instance declaration. In the instance kind, the part of "(...) =>" is skipped. What people think of this suggestion? Thank you in advance for your notes and help, ----------------- Serge Mechveliani mechvel(a)botik.ru

3 4

RE: Unexpected lack of optimisation
by Simon Peyton-Jones 01 May '08

01 May '08

| The situation in Neil's code is almost identical, except that the | top-level case expression is on a value passed by environment, not by | function argument. Interesting thought. I think you're describing a possible extension to the SpecConstr transformation described in "Call pattern specialisation for Haskell" (http://research.microsoft.com/%7Esimonpj/papers/spec-constr) f x = let g y = ...case x of { z:zs -> e1; [] -> e2 } ... in ...case x of z:zs -> if ... then g 3 else g 4 [] -> ... Here 'x' is free in 'g', but x's value is known at g's call sites. It's not enough just to know "x is a cons" inside g; we must also have access to z,zs. So perhaps the thing to do is to imagine lambda-lifting 'g' to become 'gl' thus: gl x y = ...case x of { z:zs -> e1; [] -> e2 } ... f x = ...case x of z:zs -> if ... then gl x 3 else gl x 4 [] -> ... Now the SpecConstr transformation will apply nicely. And it's arguably a bad shortcoming that currently the mere act of lambda lifting can affect how effective SpecConstr is. Of course, we only want to lambda-lift wrt the parameters that'll be specialised, so this transformation probably wants to be done at the same time as the rest of SpecConstr. I don't have much idea of how hard that'd be, but it's a nice idea. Simon

2 1

installing all of hackage
by Duncan Coutts 01 May '08

01 May '08

All, We're getting nearer to being able to use cabal-install to install all of hackage for us. :-) I did a run this evening: $ cabal install -O0 $(cat pkgs) which is a list of 485 packages. I had to prune this list manually to eliminate the ones that have unsatisfiable dependencies (about 10). I hope to add a flag to get cabal-install to do that automatically, and where we do not use that flag, to produce better error messages saying *which* packages have the unsatisfiable dependencies. So I now have 329 library packages installed. It makes me notice this issue rather acutely: http://hackage.haskell.org/trac/ghc/ticket/2089 "reading the package db is slow" In fact this would be a really big problem for doing our own make-like system where we invoke ghc once for each module. Where at the moment it takes 1 second per library/executable, it'd take one second per module. It would in fact mean that reading the package database would take more time than compilation since compilation zips through at less than one second per module on average with -O0. I've also got a list of 163 install failures. Unfortunately we do not get logs of the failing packages, just a summary like: GuiTV-0.4 depends on wxcore-0.10.3 which failed to install. xtc-1.0 depends on wxcore-0.10.3 which failed to install. phooey-2.0 depends on wxcore-0.10.3 which failed to install. GenI-0.16.1 depends on wxcore-0.10.3 which failed to install. wx-0.10.3 depends on wxcore-0.10.3 which failed to install. AutoForms-0.4.0 depends on wxcore-0.10.3 which failed to install. wxcore-0.10.3 failed during the configure step. The exception was: exit: ExitFailure 2 Still, it's progress I feel. I've also added a flag to let us choose which version of the Cabal lib to use when building packages. This should make it possible to compare building everything with Cabal-1.2 and 1.4 for example. Duncan BTW, if you're wondering about the discrepancy in package numbers, it's because I had some packages installed already, some of which were not from hackage. Some of the packages I installed were binaries for which we do not track the installed state. Also, since some packages were already installed, cabal-install did not re-install them. So I don't know how many did actually install successfully, only how many failed.

1 0

Re: Unexpected lack of optimisation
by Neil Mitchell 30 Apr '08

30 Apr '08

Hi > > Yes, something like that is exactly what I'd like to do. I'm somewhat > hopeful that we might manage this as part of Max Bolingbroke's SoC project, > if it's approved. > > > > Hmmm, I thought it had been approved. Was I mistaken? Yes, it has been approved. http://code.google.com/soc/2008/haskell/about.html Thanks Neil

1 0

Optimisation of unpackCString#
by Neil Mitchell 30 Apr '08

30 Apr '08

Hi (All these results are from GHC 6.9.20071226, but suspect they hold for 6.9.* and 6.8) The following code: test = head "neil" Produces (with -O2): Text.HTML.TagSoup.Development.Sample.test = case GHC.Base.unpackCString# "neil" of wild_aaU { [] -> GHC.List.badHead @ GHC.Base.Char; : x_aaY ds1_aaZ -> x_aaY } However: test = head ['n','e','i','l'] Produces: Text.HTML.TagSoup.Development.Sample.test = GHC.Base.C# 'n' The packing of the string has damaged the optimisation. Is there anyway to mitigate this? I ideally want to do this in RULES to derive an efficient parser from a set of parser combinators, and the unpackCString# really gets in the way of future optimisations. I could imagine adding two rules to the simplifier: case unpackCString# "" of ==> case [] of case unpackCString# "xyz" of ==> case (C# 'x': unpackCString# "yz") of Then the simplifier could recover the optimised version. Thanks Neil

5 21