June 2008 - Glasgow-haskell-users

GHC 6.8.2 and large source files
by Christian Höner zu Siederdissen 04 Jun '08

04 Jun '08

Dear Haskell users, we have an automated system that generates executable haskell source files. These files have a line count from 1,000 lines up to 28,000 lines. There is only 1 type definition and 5 functions in total in the file. We now can compile into executable code some of these programs but the compiler requires an incredible amount of memory: the 15,000 line programs easily require 2 GByte of RAM and then the compiler dies. Are there hints on how to compile large source files? Would it help, for example to compile each function on its own? On the following webpage you can find a handcrafted program, albeit with very few lines, that shows how one of our source files would look like: http://bibiserv.techfak.uni-bielefeld.de/cgi-bin/adp_MatrixMult We automatically generate type, algebras and the grammar for our application. Thanks, Christian Höner zu Siederdissen

2 2

Re: [Haskell-cafe] Default definitions for associated type synonyms
by Isaac Dupree 02 Jun '08

02 Jun '08

Dreixel wrote: > Hello, > > Does anyone know if it is possible to specify a default definition for an > associated type synonym? When I tried: > > class A a where >> type B a = a >> > > GHC (version 6.9.20080309) told me: "Type declaration in a class must be a > kind signature or synonym default". However, when I look at the parser I see > no way to specify such synonym default. Is this possible? I'm curious... so, cc'ing glasgow-haskell-users mailinglist because the question is more likely to be noticed by relevant people there. > Thanks, > Zé Pedro

2 1

impredicative polymorphism: seen on HCAR
by Isaac Dupree 02 Jun '08

02 Jun '08

The May 2008 Haskell Communities and Activities Report, GHC <http://www.haskell.org/communities/05-2008/html/report.html#ghc>: > Impredicative polymorphism. We are not happy with GHC’s current > implementation of impredicative polymorphism, which is rather > complicated and ad hoc. Dimitrios (with Simon and Stephanie) > wrote a paper about a new and better approach: > http://research.microsoft.com/~simonpj/papers/boxy > . At the same time, Daan Leijen has been working on his > closely-related design: > http://research.microsoft.com/users/daan/pubs.html > . Daan’s design has a much simpler implementation, in exchange > for an (arguably) less-predictable specification. Which of these > two should we implement? Let us know! I read the papers... Dimitrios's *paper* is easier for me to understand than Daan's. In fact they seem quite similar. I have no idea of any examples where they would behave differently. I don't use impredicative polymorphism much (but maybe because of my perception that the existing implementations are poorly designed, and that it can usually be avoided by an amount of abstraction that's useful anyway). So I'd say, implement the easier solution. Is there a paper or documentation somewhere, presenting a practical argument for why impredicative polymorphism is important in real programs (beyond runST $) -- for example, a real program that uses it and has clearer code because of it? I don't really mind writing let/function type-signatures that have weird types (unless they're long and repeat information that doesn't need to be, which is a different problem). I wonder how often these proposals require type-signatures on lambdas passed to higher-order functions, though... A side-effect is for those of us who want to have any concern for future compatibility with non-GHC type systems (or the long future of GHC's, even), whether one of the proposals would be likely to be easier for someone else to implement in a different compiler. -Isaac

1 1

Re: ANNOUNCE: GHC 6.8.3 Release Candidate
by Serge D. Mechveliani 02 Jun '08

02 Jun '08

On Sun, Jun 01, 2008 at 01:13:06AM +0100, Ian Lynagh wrote: > > Hi Serge, > > On Sat, May 31, 2008 at 12:54:50PM +0400, Serge D. Mechveliani wrote: > > This is a bug report for the ghc candidate of May 27, 2008 > > for ghc-6.8.3. > > A short program example for this bug candidate is on > > > > http://botik.ru/pub/local/Mechveliani/ghcBugs/candidateMay27-08-bug.zip > > Thanks, I've finally tracked this down. The problem is that when you > evaluate something like > f ^ 10 > in 6.8.2 the result was > res > while in 6.8.3 it is > 1 * res > > I think this is actually a bug in your class instances, but I will try > to look at http://hackage.haskell.org/trac/ghc/ticket/2306 before 6.8.3 > which should, as a side-effect, make it work again. ?? Probably, 6.8.3 is wrong. Because when res :: Num a => a, 1*res means ((fromInteger 1) :: a) * res in Haskell-98. Right? And (fromInteger n) :: a can be defined arbitrarily by the programmer. For example, DoCon has the instance instance CommutativeRing a => Num (Pol a) where ... fromInteger _ = error "No (fromInteger n) :: Pol _ !\ \Apply instead fromi <samplePolynomial> n." -- something of this kind. This is why res and 1*res are not equivalent in Haskell-98 for res :: Num a => a. Am I missing something? ----------------- Serge Mechveliani mechvel(a)botik.ru

5 6

test for 6.8.3-may27
by Serge D. Mechveliani 01 Jun '08

01 Jun '08

About the 6.8.3 candidate of May 27, there remains the question: why it builds DoCon-2.11 considerably slower than ghc-6.8.2 (3 times, as I recall) and needs larger -M memory to build this DoCon ? Regards, ----------------- Serge Mechveliani mechvel(a)botik.ru

1 0

Re: [Haskell-cafe] hint / ghc api and reloading modules
by Daniel Gorín 31 May '08

31 May '08

(Since this can be of interest to those using the ghc-api I'm cc-ing the ghc users' list.) Hi, Evan The odd behavior you spotted happens only with hint under ghc-6.8. It turns out the problem was in the session initialization. Since ghc-6.8 the newSession function no longer receives a GhcMode. The thing is that, apparently, if one was passing the Interactive mode to newSession under ghc-6.6, now you ought to set the ghcLink dynflag to LinkInMemory instead. I couldn't find this documented anywhere (except for this patch http://www.haskell.org/pipermail/cvs-ghc/2007-April/034974.html) but it is what ghci is doing and after patching hint to do this the reloading of modules works fine. I'll be uploading a fixed version of hint to hackage in the next days. Thanks, Daniel On May 31, 2008, at 2:46 PM, Evan Laforge wrote: > I'm using "hint", but since it's basically a thin wrapper around the > GHC API, this is probably a GHC api question too. Maybe this should > go to cvs-ghc? Let me know and I'll go subscribe over there. > > It's my impression from the documentation that I should be able to > load a module interpreted, make changes to it, and then reload it. > This is, after all what ghci does. It's also my impression that the > other imported modules should be loaded as object files, if the .hi > and .o exist, since this is also what ghci does. > > However, if I load a module and run code like so (using hint): > > GHC.loadModules ["Cmd.LanguageEnviron"] > GHC.setTopLevelModules ["Cmd.LanguageEnviron"] > GHC.setImports ["Prelude"] > cmd_func <- GHC.interpret (mangle_code text) (GHC.as :: LangType) > > It works fine until I change LanguageEnviron. If I make a change to a > function, I don't see my changes in the output, as if the session is > only getting partially reset. If I insert a syntax error, then I do > see it, so it is recompiling the file in some way. However, if I > *rename* the function and call it with the new name, I get a > GhcException: > > During interactive linking, GHCi couldn't find the following symbol: > ... etc. > > So I examined the code in hint for loadModules and the code in > ghci/InteractiveUI.hs:/loadModule, and they do look like they're doing > basically the same things, except a call to rts_revertCAFs, which I > called too just for good measure but it didn't help (I can't find its > source anywhere, but the ghci docs imply it's optional, so I suspect > it's a red herring). > > Here's a condensed summary of what hint is doing: > -- reset > GHC.setContext session [] [] > GHC.setTargets session [] > GHC.load session GHC.LoadAllTargets > -- rts_revertCAFs > > -- load > targets <- mapM (\f -> GHC.guessTarget f Nothing) fs > GHC.setTargets session targets > GHC.load session GHC.LoadAllTargets > > -- interpret > let expr_typesig = "($expr) :: xyz" > expr_val <- GHC.compileExpr session expr_typesig > return (GHC.Exts.unsafeCorce# expr_val :: a) > > -- GHC.compileExpr > maybe_stuff <- hscStmt hsc_env ("let __cmCompileExpr = "++expr) > ([n],[hv]) <- (unsafeCoerce# hval) :: IO [HValue] > return (Just hv) > > > and then ghci does: > -- load > GHC.setTargets session [] > GHC.load session LoadAllTargets > > targets <- io (mapM (uncurry GHC.guessTarget) files') > GHC.setTargets session targets > GHC.load session LoadAllTargets > > rts_revertCAFs > putStrLn "Ok, modules loaded: $modules" > > -- interpret > GHC.runStmt session stmt step > > -- GHC.runStmt > Just (ids, hval) <- hscStmt hsc_env' expr > coerce hval to (IO [HValue]) and run it carefully > > > So it *looks* like I'm doing basically the same thing as ghci... > except obviously I'm not because ghci reloads modules without any > trouble. Before I go start trying to make hint even more identical to > ghci, is there anything obviously wrong here that I'm doing? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe(a)haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe

1 0