- Glasgow-haskell-users

OpenGL/GLUT examples crashing: known problem?
by Tim Smith 09 Apr '05

09 Apr '05

Hi! I just got GLUT to compile with a recent GHC (tried both ghc6.4 and a fresh CVS), see: https://sourceforge.net/tracker/?func=detail&atid=108032&aid=1177838&group_… Anyways, now I did 'gmake' in GLUT/examples. Everything builds fine, but a number of the examples don't work. I.e., in RedBook: 2:39 ~/local/src/build/libraries/GLUT/examples/RedBook$ for f in `find . -type f -perm 755 -print`; do if $f >/dev/null 2>&1; then echo "$f OK"; else echo "$f failed"; fi; done ./Alpha OK ./BezCurve OK ./BezMesh failed ./BezSurf OK ./BlendEqn OK ./Checker OK ./Clip failed ./ColorMat failed ./ColorMatrix OK ./ColorTable OK ./Combiner OK ./Convolution OK ./Cube OK ./CubeMap failed ./DList OK ./Double OK ./DrawF OK ./Feedback OK ./Fog failed ./FogCoord OK ./Font OK ./Hello OK ./Histogram OK ./Image OK ./Light failed ./Lines OK ./MVArray failed ./Material failed ./Minmax OK ./Mipmap OK ./Model OK ./MoveLight failed ./MultiTex OK ./PickDepth OK ./PickSquare OK ./Planet failed ./Polys OK ./Quadric failed ./Robot OK ./Scene failed ./Select OK ./ShadowMap failed ./Smooth OK ./SurfPoints OK ./Surface failed ./Teapots failed ./Tess OK ./TexBind OK ./TessWind OK ./TexGen failed ./TexProx OK ./TexSub OK ./Texture3D OK ./TextureSurf OK ./Trim failed ./UnProject OK ./VArray OK ./Wrap OK This is probably some known bug, but I wanted to check. If so, does anyone know what the parameters are on what can be used, and what will core dump? If it's not a known bug, I'll file a bug report - any other info that would be helpful? Thank you! Tim -- If you're not part of the solution, you're part of the precipitate.

3 2

installing ghc without already having ghc
by Jessica Brennan [staff] 08 Apr '05

08 Apr '05

I am trying to install ghc-6.4 on netbsd20. I read through the install instructions, however they say you need a working copy of ghc already. "10.2. Porting GHC to a new architecture" looks to be the section I want to be in for installing ghc, however the very next thing it says you need is: 10.2.1 Cross-compiling to produce an unregisterised GHC "Firstly, you need a machine that already has a working GHC" Unfortunatly I don't have this. Is there a section I missed on building ghc that doesn't need a machine with a working copy? -Jessica ~~~~~~~~~~~~~~ jib(a)panix.com

2 2

RE: GADTs and pedagogy was Re: GADTs and fundeps
by Simon Peyton-Jones 08 Apr '05

08 Apr '05

| I doubt pedagogics was an important part of your goal with GADTs, but now | several people wish that "deriving Show" worked so that GADTs could be used for | everything. You mean, if the data type being defined doesn't actually use the generality of GADTs, allow GADT syntax, and deriving() too? S

3 2

RE: GADTs and fundeps
by Simon Peyton-Jones 08 Apr '05

08 Apr '05

Bjorn You are quite right. Indeed GADTs don't interact properly with type classes at all, let alone functional dependencies, I'm afraid. I decided to pause and release before attending to this; it's not trivial to do it right. One merit of pausing is that I can collect examples that people actually trip over, and make sure they work. Would you like to file a SourceForge bug, so that your code gets preserved there? The more people that tell us they've tripped over something in GHC, the more likely it is that we'll do something about it -- so keep telling us. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Bjorn Bringert | Sent: 06 April 2005 17:22 | To: glasgow-haskell-users(a)haskell.org | Subject: GADTs and fundeps | | GADTs and fundeps don't seem to interact in the way that I (perhaps | naively) expect. I expected that for each case, the type variables would | be instantiated according to the type of the constructors, and then the | fundep would be used to figure out the result type. This does not seem to | work, or am I doing something stupid? | | /Bjorn | | | {-# OPTIONS_GHC -fglasgow-exts #-} | | data Succ n | data Zero | | class Plus x y z | x y -> z | instance Plus Zero x x | instance Plus x y z => Plus (Succ x) y (Succ z) | | infixr 5 ::: | | data List :: * -> * -> * where | Nil :: List a Zero | (:::) :: a -> List a n -> List a (Succ n) | | {- | GHC 6.4 says: | | Couldn't match the rigid variable `y' against `Succ z' | `y' is bound by the type signature for `append' | Expected type: List a y | Inferred type: List a (Succ z) | In the expression: x ::: (append xs ys) | In the definition of `append': append (x ::: xs) ys = x ::: (append xs | ys) | -} | append :: Plus x y z => List a x -> List a y -> List a z | append Nil ys = ys | append (x ::: xs) ys = x ::: append xs ys | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

2 1

ghc6.4, cygwin, error in RawSystem
by Patrick Scheibe 06 Apr '05

06 Apr '05

Hi, I try hard to compile ghc6.4 under MS Windows XP with really new cygwin. What am I doing wrong, this is the official 6.4 release? Some hints I should know about compiling under MS Win? /cygdrive/g/ghc/ghc-6.2.1/bin/ghc -H16m -O -I. -Rghc-timing -I../../../librarie s -fglasgow-exts -no-recomp -split-objs -c Compat/RawSystem.hs -o Compat/RawS ystem.o -ohi Compat/RawSystem.hi G:/cygwin/home/mai99dnn/tmp/ghc1832.hc: In function `s3SQ_entry': G:/cygwin/home/mai99dnn/tmp/ghc1832.hc:113: too many arguments to function `rawS ystem' <<ghc: 55717388 bytes, 14 GCs, 2709857/5640724 avg/max bytes residency (3 sample s), 19M in use, 0,01 INIT (0,00 elapsed), 0,47 MUT (0,54 elapsed), 0,29 GC (0,31 elapsed) :ghc>> make[4]: *** [Compat/RawSystem.o] Error 1 make[3]: *** [boot] Error 2 make[2]: *** [boot] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/mai99dnn/software/ghc-6.4/ghc' make: *** [build] Error 1 Cheers Patrick

1 0

GADTs and fundeps
by Bjorn Bringert 06 Apr '05

06 Apr '05

GADTs and fundeps don't seem to interact in the way that I (perhaps naively) expect. I expected that for each case, the type variables would be instantiated according to the type of the constructors, and then the fundep would be used to figure out the result type. This does not seem to work, or am I doing something stupid? /Bjorn {-# OPTIONS_GHC -fglasgow-exts #-} data Succ n data Zero class Plus x y z | x y -> z instance Plus Zero x x instance Plus x y z => Plus (Succ x) y (Succ z) infixr 5 ::: data List :: * -> * -> * where Nil :: List a Zero (:::) :: a -> List a n -> List a (Succ n) {- GHC 6.4 says: Couldn't match the rigid variable `y' against `Succ z' `y' is bound by the type signature for `append' Expected type: List a y Inferred type: List a (Succ z) In the expression: x ::: (append xs ys) In the definition of `append': append (x ::: xs) ys = x ::: (append xs ys) -} append :: Plus x y z => List a x -> List a y -> List a z append Nil ys = ys append (x ::: xs) ys = x ::: append xs ys

1 0

RE: Functional dependencies, principal types, and decidable typechecking
by Simon Peyton-Jones 06 Apr '05

06 Apr '05

Manuel Your short program tickles a lot of different questions. Here's an explanation. Simon | Assume the following type class declarations with functional | dependencies: Actually much of the behaviour you see happens without fundeps. | > {-# OPTIONS -fglasgow-exts #-} | > | > class C a b c | a b -> c where | > foo :: (a, b) -> c | > | > instance C a a r => C a (b, c) r where | > foo (a, (b, c)) = foo (a, a) You are already on dodgy ground here, because the instance decl doesn't guarantee that the bit before the => is smaller than the bit after the =>. E.g. context reduction could go: C (Int,Int) (Bool, Bool) r --> C (Int,Int) (Int,Int) r --> C (Int,Int) (Int,Int) r So [Point 1]: GHC should require -fallow-undecidable-instances if you use repeated type variables before the =>. | Now, in GHCi (version 6.4), | | > *FDs> let bar x = foo ((x, x), (x, x)) | > *FDs> :t bar | > bar :: (C (a, a) (a, a) c) => a -> c | | but GHC is also happy to accept the more general type | | > bar :: a -> c | > bar x = foo ((x, x), (x, x)) There are two separate things going on here [Point 2] GHC postpones context reduction until it's forced to do it (except if a single step will eliminate the dictionary altogether). Example: data T a = T a instance Eq (T a) bar x = [T x] == [] GHC will *infer* bar :: Eq [T a] => a -> Bool, but it will happily *check* bar :: a -> Bool bar x = [T x] == [] The reason for this lazy context reduction is overlapping instances; in principle there might be more instances for Eq [T a] at bar's call site. But now I look at it again, I think it would be OK to postpone context reduction only if there actually were overlapping instances (right here at bar's defn). That might be a good idea because it'd give less confusing types perhaps. However, note that the two types are indeed equivalent -- both are more general than the other. It's like saying (Eq Int => t) <= t, and vice versa. [Point 3] As Iavor notes, yes, GHC is building recursive dictionaries. Suppose GHC is trying to find evidence for constraint C from a set of constraints (with evidence provided) D. Suppose it finds an instance decl D' => C which matches C. Then it tries to prove the constraints D'. The new bit is that it adds C to D before trying to prove D'. That's all! This is Jolly Useful sometimes. (See John Hughes's paper about restricted type synonyms for example.) It's a bit like infinite data structures. ML doesn't let you build them, so there's a static error. Haskell does, and that is sometimes just what you want; and sometimes gives you runtime divergence (e.g. take the length of an infinite list). In the same way, this recursive-dictionary thing is sometimes just what you want; but sometimes gives you runtime divergence instead of a static error. | Again, in GHCi, | | > *FDs> let bar x = foo ((x::Int, x), (x, x)) | > *FDs> :t bar | > bar :: Int -> () | | (which by itself is bizarre) This is the first time when the functional dependency plays a role. >From bar's right-hand-side we get the constraint (C (Int,Int) (Int,Int) c), and the type (Int -> c). Now GHC tries to decide what to quantify over. Shall we quantify over c? Well, no. GHC never quantifies over type variables that are free in the environment (of course) OR are fixed by functional dependencies from type variables free in the environment. In this case the functional dependencies tell us that since (Int,Int) is obviously completely fixed, then there's no point in quantifying over c. So bar is not quantified. The constraint (C (Int,Int) (Int,Int) c) is satisfied via the recursive dictionary thing, leaving 'c' completely unconstrained. So GHC chooses c to be (), because it doesn't like to leave programs with completely free type variables. | but it also accepts | | > bar :: Int -> c | > bar x = foo ((x::Int, x), (x, x)) Here you are *telling* GHC what to quantify over, so the inference of what to quantify doesn't happen.

3 2

Functional dependencies, principal types, and decidable type checking
by Manuel M T Chakravarty 05 Apr '05

05 Apr '05

Assume the following type class declarations with functional dependencies: > {-# OPTIONS -fglasgow-exts #-} > > class C a b c | a b -> c where > foo :: (a, b) -> c > > instance C a a r => C a (b, c) r where > foo (a, (b, c)) = foo (a, a) Now, in GHCi (version 6.4), > *FDs> let bar x = foo ((x, x), (x, x)) > *FDs> :t bar > bar :: (C (a, a) (a, a) c) => a -> c but GHC is also happy to accept the more general type > bar :: a -> c > bar x = foo ((x, x), (x, x)) Again, in GHCi, > *FDs> let bar x = foo ((x::Int, x), (x, x)) > *FDs> :t bar > bar :: Int -> () (which by itself is bizarre), but it also accepts > bar :: Int -> c > bar x = foo ((x::Int, x), (x, x)) For those who expected GHC to diverge during type checking with the above class declaration, console yourself by knowing that Hugs (Feb'05) does diverge...well, it invokes the emergency break: > Hugs.Base> :l FDs > ERROR "./FDs.hs" - > *** The type checker has reached the cutoff limit while trying to > *** determine whether: > *** C (Int,Int) (Int,Int) a > *** can be deduced from: > *** () > *** This may indicate that the problem is undecidable. However, > *** you may still try to increase the cutoff limit using the -c > *** option and then try again. (The current setting is -c40) Manuel

2 2

RE: compiling application with prof results in undefined references
by Simon Marlow 04 Apr '05

04 Apr '05

On 04 April 2005 12:07, Niels van der Velden wrote: > Hi all, > I have an application that uses a package called 'uust'. > Normally I would compile using; > > ghc -O2 -o genAST -fglasgow-exts -package uust GenAst.hs > > This works fine. However, I want to profile my application and > therefore need to add -prof. The uust package was compiled for > profiling (there are _p files), but when I compile using; > > ghc -prof -O2 -o genAST -fglasgow-exts -package uust GenAst.hs > > I get undefined references during the link phase; > > GenAST.o(.rodata+0xe5f0): undefined reference to > `UUziParsingziInterface_lvl8_closure' > GenAST.o(.rodata+0xe630): undefined reference to > `UUziParsingziInterface_zdwevalStepsIOzq_closure' > GenAST.o(.rodata+0xe6cc): undefined reference to > `UUziPrettyziBasic_lvl19_closure' > GenAST.o(.rodata+0xe6e8): undefined reference to > `UUziParsingziInterface_lvl8_closure' > GenAST.o(.rodata+0xe724): undefined reference to > `UUziParsingziInterface_zdwevalStepsIOzq_closure' > > and many many more. I'm kinda in the dark here what I'm doing wrong. > Can anyone help? It looks like there's something wrong with the profiling version of your uust package: either some of the object code is missing, or it doesn't correspond to the .p_hi files. I would check your uust package build. Cheers, Simon

2 2

RE: Rebindable syntax for monads and arrows
by Simon Peyton-Jones 04 Apr '05

04 Apr '05

Ross, Amr, OK. I've done rebindable syntax for do-notation, in the HEAD. Care to try it? What this means is that, with -fno-implicit-prelude, do { pat <- e; Q } has the same static semantics as e >>= (\x -> case x of { pat -> do { Q }; other -> fail "urk") where the (>>=) is whatever (>>=) happens to be in scope at that point. The situation for arrows is unchanged; no rebindable syntax. (Partly because the detailed spec is unclear.) It does *not* work for mdo, because mdo uses (>>=) at a polymorphic type. Just do-notation. Which is, I hope, enough for you. Simon | -----Original Message----- | From: Amr A Sabry [mailto:sabry@cs.indiana.edu] | Sent: 24 January 2005 19:40 | To: Simon Peyton-Jones | Cc: Amr A Sabry; ross(a)soi.city.ac.uk | Subject: Re: Rebindable syntax for monads and arrows | | > You've convinced me about the monad one; GHC doesn't implement its own | > manual! And it's not hard to fix. So it's on my to-do list. | | :-) | | > Meanwhile, I'd like to know: if I did the monad thing, would that be | > useful to you, or just a generally good thing. And if the former, how | > useful? That is, how hard should I try to get to it?! | | It would definitely be useful but not critical at this point. | | Thanks. --Amr

1 0