- Glasgow-haskell-users

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

ghci: can't load module BitSet, and some others
by Marc Weber 30 Apr '08

30 Apr '08

Hi. I'm totally puzzled: ghc-pkg describe ghc shows BitSet as exposed module. When grepping the whole ghc source code the only occurance I can find is in the package.in file for the ghc package. But that't it Trying to load it using GHC-api or ghci fails ? Is this module depreceated and only there for compatibility reasons? darcs changes reveals: Wed Oct 11 15:16:14 CEST 2006 Simon Marlow <simonmar(a)microsoft.com> * remove BitSet, it isn't used So is it time to remove it completely? I can't load all these modules: BitSet FieldLabel IlxGen Java JavaGen PrintJava RegisterAlloc So what's wrong here? Sincerly MarcWeber

2 2

Unexpected lack of optimisation
by Neil Mitchell 30 Apr '08

30 Apr '08

Hi Using GHC 6.9.20071226: The following code: ------------------------------------------------------- test s | begin2 'n' 'a' s = "test" | begin2 'n' 'b' s = "test2" begin2 :: Char -> Char -> String -> Bool begin2 x1 x2 (y:ys) | x1 == y = begin1 x2 ys begin2 _ _ _ = False begin1 :: Char -> String -> Bool begin1 x1 (y:ys) | x1 == y = True ------------------------------------------------------- You might expect the head of the list s to be tested for equality with 'n' only once. Something like: test s = case s of s1:ss -> case s1 of 'n' -> .... choose 'a' or 'b' .... _ -> fail Unfortunately, GHC can't common up these two tests. It inserts a State# RealWorld in the middle, giving a result of: test s = case s of s1:ss -> case s1 of 'n' -> case ss of s2:ss -> case s2 of 'a' -> .... _ -> retry state _ -> retry state retry dummy = case s of s1:ss -> case s1 of 'n' -> .... If GHC was to inline the "retry" (which is a local let-bound lambda) it should have no problem merging these two cases. I'm not entirely sure why the State# gets inserted, but was wondering if it is necessary? The complete -ddump-simpl is at the end of this message. Thanks Neil -------------------------------------------------------------- Text.HTML.TagSoup.Development.Sample.test :: GHC.Base.String -> [GHC.Base.Char] [GlobalId] [Arity 1] Text.HTML.TagSoup.Development.Sample.test = \ (s_a6g :: GHC.Base.String) -> let { $j_s7l :: GHC.Prim.State# GHC.Prim.RealWorld -> [GHC.Base.Char] [Arity 1] $j_s7l = \ (w_s7m :: GHC.Prim.State# GHC.Prim.RealWorld) -> let { $j1_s7d :: GHC.Prim.State# GHC.Prim.RealWorld -> [GHC.Base.Char] [Arity 1] $j1_s7d = \ (w1_s7e :: GHC.Prim.State# GHC.Prim.RealWorld) -> GHC.Err.patError @ [GHC.Base.Char] "Text/HTML/TagSoup/Development/Sample.hs:(48,0)-(49,34)|function test" } in case s_a6g of wild_Xl { [] -> $j1_s7d GHC.Prim.realWorld#; : y_a6o ys_a6q -> case GHC.Base.$f4 of tpl_Xr { GHC.Base.:DEq tpl1_B2 tpl2_B3 -> case tpl1_B2 (GHC.Base.C# 'n') y_a6o of wild1_Xp { GHC.Base.False -> $j1_s7d GHC.Prim.realWorld#; GHC.Base.True -> let { fail_d6S :: GHC.Base.Bool [] fail_d6S = GHC.Err.patError @ GHC.Base.Bool "Text/HTML/TagSoup/Development/Sample.hs:57:0-32|function begin1" } in case ys_a6q of wild2_XB { [] -> case fail_d6S of wild3_Xj { GHC.Base.False -> $j1_s7d GHC.Prim.realWorld#; GHC.Base.True -> GHC.Base.unpackCString# "test2" }; : y1_a6y ys1_a6A -> case GHC.Base.$f4 of tpl3_XH { GHC.Base.:DEq tpl4_XL tpl5_XN -> case tpl4_XL (GHC.Base.C# 'b') y1_a6y of wild3_Xo { GHC.Base.False -> case fail_d6S of wild4_Xj { GHC.Base.False -> $j1_s7d GHC.Prim.realWorld#; GHC.Base.True -> GHC.Base.unpackCString# "test2" }; GHC.Base.True -> GHC.Base.unpackCString# "test2" } } } } } } } in case s_a6g of wild_B1 { [] -> $j_s7l GHC.Prim.realWorld#; : y_a6o ys_a6q -> case GHC.Base.$f4 of tpl_Xp { GHC.Base.:DEq tpl1_B2 tpl2_B3 -> case tpl1_B2 (GHC.Base.C# 'n') y_a6o of wild1_XT { GHC.Base.False -> $j_s7l GHC.Prim.realWorld#; GHC.Base.True -> let { fail_d6S :: GHC.Base.Bool [] fail_d6S = GHC.Err.patError @ GHC.Base.Bool "Text/HTML/TagSoup/Development/Sample.hs:57:0-32|function begin1" } in case ys_a6q of wild2_Xz { [] -> case fail_d6S of wild3_XD { GHC.Base.False -> $j_s7l GHC.Prim.realWorld#; GHC.Base.True -> GHC.Base.unpackCString# "test" }; : y1_a6y ys1_a6A -> case GHC.Base.$f4 of tpl3_XF { GHC.Base.:DEq tpl4_XJ tpl5_XL -> case tpl4_XJ (GHC.Base.C# 'a') y1_a6y of wild3_Xo { GHC.Base.False -> case fail_d6S of wild4_XN { GHC.Base.False -> $j_s7l GHC.Prim.realWorld#; GHC.Base.True -> GHC.Base.unpackCString# "test" }; GHC.Base.True -> GHC.Base.unpackCString# "test" } } } } } }

5 9

Re: [Haskell-cafe] retrospective on 'seq' -> 'unsafeSeq' ?
by pepe 30 Apr '08

30 Apr '08

On 14/04/2008, at 12:19, Simon Peyton-Jones wrote: > | > type constraints accordingly. (Analogously there could be an > unsafeShow that > | > allows showing offending values in an 'error' without adding a > Show > | > constraint to the type signature.) > | > | Ideally, unsafeShow could also show types as they are underneath, > not > | as a pretty-printing Show might show them. I have often wanted to > | overload Show to print things in a readable way, but to have a > showRaw > | which shows things as they are, for debugging purposes. I have even > | written such code for Yhc: > | http://www.cs.york.ac.uk/fp/yhc/snapshot/docs/Yhc-Core-ShowRaw.html > | > | I think unsafeShow is a fantastic idea - and would be much more > useful > | to me than unsafeSeq - plus is a non-breaking change. I think Hugs > | already has 90% of the code to support this, and GHCi's debugger I > | think has a fair chunk of it, so it could be added given not too > much > | work. > > Yes, as you say, the debugger has most of the machinery. I just > don't know what it'd take to make it a callable function. Pepe? > > Someone might want to make a feature-request ticket for this, with > as much background and/or suggested design as poss. unsafeShow sounds quite useful, especially to avoid adding a Show constraint in function signatures only for debugging (of course a decent refactoring tool for Haskell would help with this too, so I hope the HaRe SoC project proposal gets accepted and done!). :print has the code for doing this, but it needs the type information collected by the compiler. In GHC API speak, it needs the HscEnv from the Session object. If we can expose the Session created for GHCi (how? exporting it from GHC.Main? in a thread-local object? FFI trickery?), then this would need nearly zero work, albeit it would print things only when working in GHCi of course. But you can still compile all your modules to object code and call main from GHCi, so I don't think this is a big restriction considering unsafeShow is only for debugging purposes. Another question is where in the package hierarchy would this function live. Since the code it would use is in the ghc package, it would introduce a dependency on it. And I am fairly sure that there is no package in the standard ghc distribution which depends on the ghc package. Ian, can it be made to live in ghc-prim without creating a dependency on the ghc package? Alternatively, with some effort one can create a type-agnostic version of unsafeShow, which would print things in a more raw format, but probably sufficient anyway. I don't think it would work with unboxed values in general, although it can be made to work with the standard types. Actually, Bernie Pope wrote some code for this [1, see GHC Heap Printing library] some time ago, although with the new primitives and changes made for :print in GHC 6.8, this would be way easier nowadays. No need to use StablePtrs, no need to turn on profiling, and above all, no C needed :) And as a bonus this would work out of GHCi too. If there is a clean way to access the Session object, the first option means less implementation work, less code to maintain in GHC, and better functionality. What does the GHC team think? [1] - http://www.cs.mu.oz.au/~bjpop/code.html

3 3

Error Interpreting Main with API
by C.M.Brown 28 Apr '08

28 Apr '08

Hello, I am trying to use the API to interpret a Main module and get some type information from it. However, everytime I try to load a "Main.hs" module using the API I get the following error message: /usr/local/packages/ghc-6.8.2/lib/ghc-6.8.2/libHSrts.a(Main.o): In function `real_main': Main.c:(.text+0x7): undefined reference to `__stginit_ZCMain' Main.c:(.text+0x36): undefined reference to `ZCMain_main_closure' collect2: ld returned 1 exit status If I create an empty file called "Main" within the directory where "Main.hs" is located the program suceeds, I'm guessing this is because there is no linking involved. Is there an extra flag I need to pass to GHC in order to avoid this error? It works perfectly if I try it on a module that is not called Main. main = defaultErrorHandler defaultDynFlags $ do let packageConf = "/usr/local/packages/ghc-6.8.2/lib/ghc-6.8.2" session <- GHC.newSession {-JustTypecheck-} (Just (filter (/= '\n') packageConf)) dflags0 <- getSessionDynFlags session (f1,b) <- parseDynamicFlags dflags0 ["-fglasgow-exts"] setSessionDynFlags session f1{verbosity=6, hscTarget = HscInterpreted} target <- GHC.guessTarget "/home/cmb21//HaRe_Project/testing/subIntroPattern/Main.hs" Nothing hscTarget=HscNothing} GHC.addTarget session target GHC.load session GHC.LoadAllTargets usermod <- findModule session (mkModuleName "Main") Nothing setContext session [usermod] [] return session I hope somebody can share some light! Kind regards, Chris.

3 6

strictness of interpreted haskell implementations
by Geraint Jones 25 Apr '08

25 Apr '08

Are there well-known differences in the implementations of Haskell in ghci and hugs? I've got some moderately intricate code (simulations of pipelined processors) that behave differently - apparently because ghci Haskell is stricter than hugs Haskell, and I cannot find any obviously relevant claims about strictness in the documentation.

4 3