- Glasgow-haskell-users

OpengGL lockup using GHC 6.6 on Intel Mac
by Joe Jones 02 Dec '06

02 Dec '06

I just installed ghc 6.6 from MacPorts and am trying to use the Haskell ported NeHe OpenGL lessons to play with OpenGL. Unfortunately, when I load the lesson in ghci and then run main the screen turns to garbage and I am forced to power cycle the machine to get back to my desktop. It's not a complete lockup as I an Alt-Tab between apps and the selector UI appears. Selecting an app, though, does nothing and I have no access to the desktop. Anyone know of any issues with the current HOpenGL on Intel? The code comes from this link: http://www.codersbase.com/index.php/Nehe-tuts Don't worry about darcs. You can select the URL for the repo and get the code directly form there. Thanx, joe

4 8

runghc -fglasgow-exts issues
by Vyacheslav Akhmechet 02 Dec '06

02 Dec '06

I need to pass -fglasgow-exts to runghc. It appears that if the first flag to runghc is -f, it treats it as a path to GHC itself. So, I cannot do the following: > runghc -fglasgow-exts Test.hs because runghc failes (it says it can't find glasgow-exts). However if I do this: > runghc -fc:/ghc/bin/ghc.exe -fglasgow-exts Test.hs it works. Is this the expected behavior? I really don't want to pass full path to GHC in order to simply specify -fglasgow-exts. I could fool runghc by doing this: > runghc -v -fc:/ghc/bin/ghc.exe -fglasgow-exts Test.hs and it'll work since the first argument isn't -f, but I really don't want to do this (if I have to, what's a good argument that does nothing?). Thanks, - Slava.

2 1

newtype deriving clause ceases to work in HEAD
by Mathieu Boespflug 01 Dec '06

01 Dec '06

Hi, The following code compiles with GHC 6.4.2, but does not typecheck with GHC HEAD pulled on Sunday. module CompilerMonad where import Control.Monad import Control.Monad.Reader import Control.Monad.Error newtype CompilerError = CE String deriving Error newtype CM r a = CM (ReaderT r (ErrorT CompilerError (Either CompilerError)) a) deriving (Monad, MonadReader a, MonadError CompilerError) Compiling the code gives: $ /home/mboes/src/ghc/compiler/stage2/ghc-inplace /tmp/CompilerMonad.hs /tmp/CompilerMonad.hs:10:8: Can't make a derived instance of `MonadReader a (CM r)' (even with cunning newtype deriving: the eta-reduction property does not hold) When deriving instances for `CM' whereas with 6.4.2 $ ghc-6.4.2 --make /tmp/CompilerMonad.hs Chasing modules from: /tmp/CompilerMonad.hs Compiling CompilerMonad ( /tmp/CompilerMonad.hs, /tmp/CompilerMonad.o ) As the above code seemed to be doing what I meant for it to do in 6.4.2, and the docs for HEAD don't seem to have changed, I'm curious as to why this doesn't work in HEAD anymore, and indeed, if this is perhaps a regression? Thanks, Mathieu

2 2

Re: RULES and strictness
by Kirsten Chevalier 01 Dec '06

01 Dec '06

> > when performing strictness/abscence/one-shot analysis, are rule bodies > taken into account? No. > like, would the following cause trouble making const > no longer absent in its second argument? > > const x y = x > > {-# RULE "const/seq" forall a b . const a b = seq b a #-} > > by trouble I mean the compiler failing or producing bad code in some > way, rather than the obvious trouble of changing the meaning of const. > No, because of the worker/wrapper transform. You can think of strictness analysis as doing something like this in this case: const x y = x => const x y = constW x constW x = let y = error "entered absent argument!" in x (of course, strictness analysis only does the work of determining that const is absent in its second argument, and the worker/wrapper transform phase is a separate pass that happens later.) So, from then on, GHC will inline const wherever possible, and the rule "const/seq" will no longer be applicable, because it applies to const, not constW. Note that even if const doesn't end up getting inlined for some reason, the presence of the rule doesn't cause any problems. It's perfectly valid to replace (const a b) with (constW a) or with (seq b a). > it is noted in the deforestation papers that rules can change the > sharing properties of code and we are okay with that. I was wondering if > they could safely change the strictness or abscence properties of code > as well? > Given the example above, I think it's fairly safe to say that rules can safely change strictness and absence properties, or at least "safe" in the sense that it shouldn't cause the compiler to crash or to generate code that crashes. (Since even GHC's strictness analysis on its own, ignoring the presence of rules, hasn't been formally proven correct yet, I'm being rather hand-wavy in saying that.) But, it is kind of weird to have a rule that changes these properties. I realize the example you gave is just for the sake of argument, but I can't think of a real situation where you'd want to have a rule that changed strictness properties (rather than expressing the strictness you wanted in the code), though I'm open to being convinced otherwise. Cheers, Kirsten -- Kirsten Chevalier* chevalier(a)alum.wellesley.edu *Often in error, never in doubt "I flip on the television and watch sad movies / And look for sad sick people like me" -- Tegan and Sara

1 0

RULES and strictness
by John Meacham 01 Dec '06

01 Dec '06

when performing strictness/abscence/one-shot analysis, are rule bodies taken into account? like, would the following cause trouble making const no longer absent in its second argument? const x y = x {-# RULE "const/seq" forall a b . const a b = seq b a #-} by trouble I mean the compiler failing or producing bad code in some way, rather than the obvious trouble of changing the meaning of const. it is noted in the deforestation papers that rules can change the sharing properties of code and we are okay with that. I was wondering if they could safely change the strictness or abscence properties of code as well? John -- John Meacham - ⑆repetae.net⑆john⑈

1 0

Re: FW: GHC API: Problems with implementing ":reload" for "ghc --make"
by Ian Lynagh 30 Nov '06

30 Nov '06

Hi Brian, Sorry for the delayed response. > My goal is to write a program GhcRemake that works like "ghc --make." > However, instead of terminating after compilation is done, I want the > program to stay open and wait for me to hit <ENTER>. When I hit > <ENTER>, GhcRemake rebuilds the project, just as if I had called "ghc > --make" again with the same arguments. The benefit of such a program > is that GhcRemake should be able to cache a lot of data in memory > between invocations and hopefully be able to do the subsequent > re-makes much faster. Nice idea! > My program seems to work fine when run on itself and when run on > Cabal. But, these two packages seem to be too small to notice any > reduction of building time. So, I decided to test my program by > building the GHC API with it. Unfortunately, it seems like every build > after the first one in the session does the dependency analysis badly, > and things get recompiled unnecessarily. It looks like the problem is caused by recursive module imports. I've added a bug (#1027) with a smaller example of it. Thanks Ian

3 2

Common subexpression elemination (CSE)
by Christian Maeder 29 Nov '06

29 Nov '06

the following code does not run as fast as expected: modexp a e n = if e <= 0 then 1 else if even e then mod (modexp a (div e 2) n * modexp a (div e 2) n) n else mod (a * modexp a (e - 1) n) n it gets only fast if written as: modexp2 a e n = if e <= 0 then 1 else if even e then let d = modexp2 a (div e 2) n in mod (d * d) n else mod (a * modexp2 a (e - 1) n) n I wonder, why the common subexpression "modexp a (div e 2) n" is not eliminated in the first case. Does CSE work at all? For testing the exponent "e" should have at least 10 digits. Cheers Christian P.S. Other alternatives are slower, too modexp1 a e n = if e <= 0 then 1 else mod (a * modexp1 a (e - 1) n) n modexp3 a e n = mod (a ^ e) n

6 8

Re: Common subexpression elemination (CSE)
by Dinko Tenev 29 Nov '06

29 Nov '06

On 11/28/06, Mark T.B. Carroll <mark(a)ixod.org> wrote: > > "Dinko Tenev" <dinko.tenev(a)gmail.com> writes: > (snip) > > How exactly can CSE cause space leaks, and what does this have to do > > with strictness? > > I puzzled over Lennart's comment too, and the theory I formed was that > you might have the same expression used in different parts of a > function, where the compiler hasn't realised that the remaining > reference to the expression is in a part of the function that isn't > going to be executed this time, so it is holding on to the expression's > value even though it is never going to be used. (For instance, with a > recursive function, all the previous calls may be holding on to their > version of the value until the call stack has come back out past them > again.) > > -- Mark > > I see this as a special case of Lennart's point -- you're talking about references that are practically dead (just not burried yet :) The compiler should probably be able to kill these early by a CPS transform, shouldn't it? -- Cheers, Dinko

2 1

Using GHC API
by C.M.Brown 29 Nov '06

29 Nov '06

Hi, I am currently in the process of porting some of the Haskell Refactorer (HaRe) over to ghc 6.6. Part of HaRe requires the API and until now I've been content with using th 6.5 API. However, since I've started the switch I've noticed some strange problems and the latest is I am getting the following error when trying to find the type of an expression: <interactive>:1:0: Can't find interface-file declaration for Main.main Probable cause: bug in .hi-boot file, or inconsistent .hi file Use -ddump-if-trace to get an idea of which file caused the error I have attached the code and would appreciate if someone could point me in the right direction. Basically I just want to find the type of a particular expression within a file. This used to work but now seems to fail. The code is compiled with: ghc --make -package ghc-6.6 -o main hasktags.hs and run with ./main Main.hs The file main can have anything in it really - I'm just using it to find a type of some function called main. Thanks for you help! Chris Brown.

3 3

bignums, gmp, bytestring, .. ?
by Claus Reinke 28 Nov '06

28 Nov '06

it seems that haskell versions of bignums is pretty much gone from more recent discussions of gmp replacements. now, I assume that there are lots of optimizations that keep gmp popular that one wouldn't want to have to reproduce, so that a haskell variant might not be competitive even if one had an efficient representation, but - do all those who want to distribute binaries, but not dynamically linked, need bignums? - it would be nice to know just how far off a good haskell version would be performance-wise.. - what would be a killer for numerical programming, might still be quite acceptable for a substantial part of haskell uses? of course, the real gmp replacement project might be going so well that a haskell version would be obsolete rather sooner than later, and i certainly don't want to interfere with that effort. all that being said, it occurred to me that the representations and fusions described in the nice "rewriting haskell strings" paper would be a good foundation for a haskell bignum project, wouldn't they? http://www.cse.unsw.edu.au/~dons/fps.html http://hackage.haskell.org/trac/ghc/wiki/ReplacingGMPNotes has anyone been looking into this option? just another thought, claus ps. while I'm at it: claiming that "array fusion .. has received comparatively little attention" sounds a bit dangerous to me, and the references are all too limited - even if you meant "in the Haskell world" (and PADL is no Haskell event). you might want to try searching with some other search terms, keeping in mind that most of the work will have been done for not so declarative languages: it isn't my area, but "loop fusion" and "with-loop folding" come to mind, and I'm sure that all those array language and numerical programming folks would be rather, well, disappointed?, to see their efforts ignored like that.

7 12