- Glasgow-haskell-users

bug in compacting GC
by Bulat Ziganshin 08 Feb '06

08 Feb '06

Hello , yes, i found this famous "-c" bug! the humor of situation is what easiest way to got this bug is to run ghc itself! :) it seems that noone except me tried this ever. i just found that any large enough module raises this error!!! that, for example, results of compiling Data.Map module: >ghc Map.hs -cpp +RTS -c ghc.EXE: internal error: update_fwd: unknown/strange object 39004 Please report this as a bug to glasgow-haskell-bugs(a)haskell.org, or http://www.sourceforge.net/projects/ghc/ ghc 6.4.1/mingw32. the error is absolutely reproducible, so at least now we had case, even lot of cases :) or you wanna a smaller program? :) -- Best regards, Bulat mailto:bulatz@HotPOP.com

2 3

RE: optimistic evaluation
by Simon Peyton-Jones 08 Feb '06

08 Feb '06

| What is the status of Rob Ennals' optimistic evaluation work? I'm told | that it has been removed from GHC. This is extremely depressing to me. More precisely, it never got into GHC. It was always on a heavily-modified branch. Rob's thesis was fantastic work. But although it sounded simple to start with, when he'd worked out all the details it was very, very complicated. Read his thesis! Simon and I decided that it was too big a complication to drag into our main compiler, and then maintain in perpetuity. It would not be so bad if it was a somewhat orthogonal feature, but it wasn't -- it percolated into many bits of the compiler and runtime system. It was cool stuff. Maybe bright person can figure out an easier way to do it. But I'm afraid we have no plans to incorporate it at the moment. Having said that, it wasn't a silver bullet! I very much doubt that it makes the difference between Haskell being usable for your work in machine learning, and not being usable. You may well need control over space, which is undoubtedly Haskell's weak spot. But remember, lazy evaluation can *reduce* space usage as well as increase it --- and the profiling tools plus seq and (perhaps!) bang patterns may give you the control you need. Simon

1 0

optimistic evaluation
by Frederik Eaton 08 Feb '06

08 Feb '06

Hi all, What is the status of Rob Ennals' optimistic evaluation work? I'm told that it has been removed from GHC. This is extremely depressing to me. Without such a feature available, it becomes very difficult to write programs that process large amounts of data in Haskell. In many such applications, strictness annotations become not just important for performance, but necessary to get a program to function at all. With optimistic evaluation, GHC and Haskell would have been at least potential candidates for my programming work in machine learning; without it I fear that this is no longer the case. Will optimistic evaluation ever be present in GHC again? What is its priority, compared to other features which are being implemented? What was the last (if any) version of GHC with optimistic evaluation present? Thanks, Frederik

2 3

RE: Re[2]: [GHC] #649: class declaration accepts conop as method name
by Simon Peyton-Jones 07 Feb '06

07 Feb '06

I agree 100% with you. We absolutely do intend to support 6.4.2 as a stable compiler for a long time yet. But this particular bug has been in the compiler for years, and only reported once. I very much doubt that anyone will even notice whether or not we fix 6.4.2. Still, if any two people (counting you as one) think they will notice, we'll certainly do it! Simon | -----Original Message----- | From: Bulat Ziganshin [mailto:bulatz@HotPOP.com] | Sent: 06 February 2006 19:39 | To: Simon Peyton-Jones | Cc: glasgow-haskell-users(a)haskell.org | Subject: Re[2]: [GHC] #649: class declaration accepts conop as method name | | Hello GHC, | | Monday, February 06, 2006, 7:59:24 PM, you wrote: | G> #649: class declaration accepts conop as method name | G> Type: bug | Status: closed | | G> Fixed in HEAD but wont't fix in 6.4.2 | | why you are not fixing this bug in 6.4.2? imho, we need to have more | stable GHC versions that can be used by the "real world" developers | like Joel Reymont just to work on their projects without reporting | each week new problem he is found in "stable" branch | | i/m trying to say that for wider GHC usage it should be more stable | than feature-rich and all new features that implemented in 6.4 or will | be implemented in 6.6 don't overweight for developers of large, | commercial apps importance of compiler stability and bug-free. i think | that GHC team should support previous version of compiler as long as | new version don't proved that it is bug-free. in this respect, even | 6.4 cannot be considered as stable version - it contains a number of | known and yet unfixed bugs and more arised as time goes. and at this | time you don't fix errors even in this version. so, that version of | GHC can be used to work on commercial projects? | | -- | Best regards, | Bulat mailto:bulatz@HotPOP.com | |

1 0

Re[2]: [GHC] #649: class declaration accepts conop as method name
by Bulat Ziganshin 06 Feb '06

06 Feb '06

Hello GHC, Monday, February 06, 2006, 7:59:24 PM, you wrote: G> #649: class declaration accepts conop as method name G> Type: bug | Status: closed G> Fixed in HEAD but wont't fix in 6.4.2 why you are not fixing this bug in 6.4.2? imho, we need to have more stable GHC versions that can be used by the "real world" developers like Joel Reymont just to work on their projects without reporting each week new problem he is found in "stable" branch i/m trying to say that for wider GHC usage it should be more stable than feature-rich and all new features that implemented in 6.4 or will be implemented in 6.6 don't overweight for developers of large, commercial apps importance of compiler stability and bug-free. i think that GHC team should support previous version of compiler as long as new version don't proved that it is bug-free. in this respect, even 6.4 cannot be considered as stable version - it contains a number of known and yet unfixed bugs and more arised as time goes. and at this time you don't fix errors even in this version. so, that version of GHC can be used to work on commercial projects? -- Best regards, Bulat mailto:bulatz@HotPOP.com

1 0

RE: instance inference
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

Interesting example. Yes, GHC builds recursive dictionaries these days. There's a bit of discussion in our SYB paper in ICFP'05. http://research.microsoft.com/%7Esimonpj/papers/hmap/ And Martin Sulzmann has a whole paper about this point. http://www.comp.nus.edu.sg/~sulzmann/ ("Co-induction...") Simon | -----Original Message----- | From: glasgow-haskell-users-bounces(a)haskell.org [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Ross Paterson | Sent: 12 December 2005 10:46 | To: glasgow-haskell-users(a)haskell.org | Subject: instance inference | | I'm puzzled that the following is accepted. Is some sort of greatest | fixed point computation used for instances? | | {-# OPTIONS_GHC -fglasgow-exts #-} | module M where | | class C a b where c :: a -> b -> Bool | | instance C b b => C (Maybe a) b where c x y = c y y | | f :: Maybe a -> Bool | f x = c x x | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users

4 7

RE: Lexically scoped type variables
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

| That was exactly my problem. How should I find out the type of | attachListOp (I have not written this bit of code)? Could I somehow ask | ghci-6.4.1 to do it for me? (Unsatisfactory but would work) You could compile with -ddump-ds and look at the output. Simon

2 1

RE: Lexically scoped type variables
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

I took a look. Here's a typical example: newVariableListFromSet :: Ord a => VariableSetSource a -> VariableList a newVariableListFromSet (variableSetSource :: VariableSetSource a) = let attachListOp parallelX (listDrawer :: ListDrawer a pos) = do (posRegistry :: Registry a pos) <- newRegistry groupingCount <- newIORef 0 let updateFn :: VariableSetUpdate a -> IO () updateFn (AddElement a) = do addElement a ... To fix this you'd need to a) Add a 'forall a.' to the sig for newVariableListFromSet. That brings 'a' into scope in the defn of the function. (Arguably, the *implicit* foralls should be in scope too; I'd be interested in what you think.) b) Add a type signature for attachListOp, beginning with forall pos. .... The main thing we're creeping towards is making it clear where scoped type variables are quantified. For example, is attachListOp polymorphic in 'pos'? We are thinking about allowing you to bind the polymorphic type variables of a function in patterns *on the left* of the '='. That would make you happy, I think. Simon | -----Original Message----- | From: Christian Maeder [mailto:maeder@tzi.de] | Sent: 02 February 2006 17:19 | To: Simon Peyton-Jones; GHC Users Mailing List | Subject: Re: Lexically scoped type variables | | > | Simon Peyton-Jones wrote: | > | > I'm very interested to know whether you like it or hate it. | > | > In the latter case, I'd also like to know whether you also | > | > have programs that will be broken by the change. | > | | > | I don't use GADTs yet and I assume this change will not (seriously) | > | break our code, but let me/us know which compiler we should use for | > testing. | | I've installed now ghc-6.5.20060201 and I get quite a few errors of the | form: | | A pattern type signature cannot bind scoped type variables `s' | unless the pattern has a rigid type context | | (and these are not always easy to fix in unknown non-haskell98 code by | adding a "forall" and/or omitting the pattern type signatures) | | Christian | | You may try to translate the attached sources by: | | ghc --make -cpp -fallow-undecidable-instances -fglasgow-exts | VariableList.hs | | (and tell me how I should fix this)

2 1

RE: instance inference
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

| I have not followed this completely, but do these new rules now allow: | | class F a b c where | f: a -> b -> c | | instance F a a a where Ross's proposal would allow that. Ignore functional dependencies for the moment. To force instance inference to terminate we need the context of the instance declaration to be "smaller" than the head. Otherwise you can get instance Foo [a] => Foo a One way to do that is to require (a) only type variables in the context (b) at least one non-type-variable as a type-class arg in the head Thus instance Foo a => Foo [a] satisifies (b) because [a] is not a type variable. This check is wildly conservative. One can ensure that things get smaller with something weaker, as Ross suggests. And that would be useful, because it'd provide a machine check of termination (necessarily still approximate), which is better than -fallow-undecidable-instances. However matters get significantly more complicated with fundeps. For example (a) and (b) are not enough. Whether Ross's suggestion guarantees termination when we have fundeps I am not sure Simon

1 0

RE: instance inference
by Simon Peyton-Jones 06 Feb '06

06 Feb '06

| > Yes, (1-GHC) certainly contradicts the FD paper that Martin and I wrote. | > I think (1) should be: | > | > (1-fixed) Each assertion in the context must constrain type | > variables, and | > those type variables must all be mentioned in the head. | > | > That is, there is no requirement that the type variables should be | > distinct (they can be repeated). But they must all appear in the HEAD. | | Ah, but you added the no-repetition requirement a few weeks ago in | response to the example | | class C a b | instance C b b => C (Maybe a) b Oh yes. And in fact I now remember that this is a bug in the paper: the Basic Conditions should require *distinct* type variables. So I take back that bit. Simon

1 0