August 2001 - Glasgow-haskell-users

RE: ghc --make and memory
by Simon Marlow 23 Aug '01

23 Aug '01

> I am finding that very large compilations fall over with ghc > --make because ghc --make > runs out of heap space. However if I restart them they > manage to continue. Is there a > way of making ghc --make use memory more efficiently? Bashing on GHC's memory use is something we want to do, but it'll be after the 5.02 release. Retainer and lag-drag-void profiling is going in post-5.02 too, which should help us track down any space leaks. Meanwhile, memory is cheap at the moment! Cheers, Simon

1 0

ghc --make and memory
by George Russell 23 Aug '01

23 Aug '01

I am finding that very large compilations fall over with ghc --make because ghc --make runs out of heap space. However if I restart them they manage to continue. Is there a way of making ghc --make use memory more efficiently?

1 0

RE: Newbie: Mutable Arrays
by Simon Marlow 23 Aug '01

23 Aug '01

> I find two versions of Mutable arrays ie STArray and > IOArray. What is the > difference between them. Where each of them are supposed to be used? STArray is for use in the ST monad (see the ST module), and IOArray is used in the IO monad. Otherwise, the behaviour is identical. Also check out MArray for overloaded mutable arrays, which let you abstract away from the actual monad and use the same function names for either - they even let you use strict unboxed arrays just by changing type signatures. Cheers, Simon

1 0

RE: Problems with scoped type variables and existential data constructors
by Simon Peyton-Jones 21 Aug '01

21 Aug '01

| | /tmp/t.hs:8: | | Could not deduce `Silly a1 t' from the context (Silly a t) | | Probable fix: | | Add `Silly a1 t' | | to the the existential context of a data constructor | | arising from use of `Exist' at /tmp/t.hs:8 | | in the definition of function `applyId': Exist (Id x) | | The trouble is that | Exist :: forall a, t. Silly a t => Exist t | | Now this is an ambigous type, Sorry, I was wrong about this. The type should be data Exist a = forall t. Silly a t => Exist t Exist :: forall a, t. Silly a t => t -> Exist a So it's not ambiguous; but my other comment was right. In your example: | > applyId (Exist x) = Exist (Id x) the LHS pattern discharges the constraint (Silly a1 t), but the RHS introduces the constraint (Silly a2 t), and there's no connection between t1 and t2. Why should there be? You could give a type signature applyId :: Exist a -> Exist a and that would force them to be the same S Simon

2 1

RE: end of the 'evil mangler' ?
by Simon Marlow 21 Aug '01

21 Aug '01

> Are we ever likely to see the end of the 'evil mangler'? > With gcc 3.x and it's selection of __atribute__ annotations > (eg noreturn, > pure, const, naked etc) would we be able to iliminate the need for the > mangler? It's not quite there yet. 'naked' looks promising, but the documentation seems to indicate that it doesn't work on all platforms. Also, you need to be able to specify the relative layout of code and data - i.e. layout data in the code section next to a specific chunk of code. We have at various times discussed ways to get rid of the mangler, but all the choices seemt to imply a compromise of one kind or another, on top of being a significant investment in developer effort. That's not to say we won't do it, provided we can settle on a good plan, or that we wouldn't welcome someone else doing it :-) Cheers, Simon

1 0

end of the 'evil mangler' ?
by Duncan Coutts 21 Aug '01

21 Aug '01

Hi all, Are we ever likely to see the end of the 'evil mangler'? With gcc 3.x and it's selection of __atribute__ annotations (eg noreturn, pure, const, naked etc) would we be able to iliminate the need for the mangler? http://gcc.gnu.org/onlinedocs/gcc-3.0/gcc_5.html#SEC92 What kind of annotations would gcc need before we could dump the mangler? Duncan Ps. this is all just wishful thinking, as I'm currently faced with the prospect of modifying the EM. http://www.cse.unsw.edu.au/~chak/haskell/ghc/comm/the-beast/mangler.html

1 0

RE: Problems with scoped type variables and existential data constructors
by Simon Peyton-Jones 21 Aug '01

21 Aug '01

The first is a bug, thank you very much. Fixed in the upcoming release. The second is not a bug: see inline comments below. Simon | -----Original Message----- | From: Dylan Thurston [mailto:dpt@math.harvard.edu] | Sent: 21 August 2001 06:17 | To: glasgow-haskell-users(a)haskell.org | Subject: Problems with scoped type variables and existential | data constructors | | | I've been getting some slightly strange behaviour from ghc | 5.00.2 using existential data constructors, and I wonder if | it's correct. | | The first is that I can't seem to use scoped type variables | when matching against an existential data constructor. That is, | | > data Exist = forall a. Exist a | > | > bottom (Exist (_ :: t)) = Exist (undefined :: t) | | gives me the error | | Inferred type is less polymorphic than expected | Quantified type variable `a' is unified with `t' | When checking a pattern that binds | In an equation for function `bottom': | bottom (Exist (_ :: t)) = Exist (undefined :: t) | | I can work around this, as follows: | | > bottom' (Exist x) = case x of {(_::t) -> Exist (undefined :: t)} | | but it is annoying. | | | The second case may have to do with context reduction. Consider | | > class Silly a b | > | > data Exist a = forall t. Silly a t => Exist t | > | > data Id x = Id x | > instance (Silly a b) => Silly a (Id b) | > | > applyId (Exist x) = Exist (Id x) | | This gives me | | /tmp/t.hs:8: | Could not deduce `Silly a1 t' from the context (Silly a t) | Probable fix: | Add `Silly a1 t' | to the the existential context of a data constructor | arising from use of `Exist' at /tmp/t.hs:8 | in the definition of function `applyId': Exist (Id x) The trouble is that Exist :: forall a, t. Silly a t => Exist t Now this is an ambigous type, (which GHC doesn't current report, something I will fix), unless there's a functional dependency from t->a. So the two calls to Exist in the LHS and RHS have different 'a's, and that's why you can't discharge one with theother. Simon

1 0

GHC on Alpha
by Ken Shan 21 Aug '01

21 Aug '01

Hello, FYI-- I am porting GHC to the Alpha. I have 5.00.2 working (except GHC interactive, calling Haskell from C (the adjustor stuff), and native code generation). There will most likely be binary and HC distributions in the next release for the Alpha. -- Edit this signature at http://www.digitas.harvard.edu/cgi-bin/ken/sig I saw my inner child once, on a milk carton.

1 0

Problems with scoped type variables and existential data constructors
by Dylan Thurston 21 Aug '01

21 Aug '01

I've been getting some slightly strange behaviour from ghc 5.00.2 using existential data constructors, and I wonder if it's correct. The first is that I can't seem to use scoped type variables when matching against an existential data constructor. That is, > data Exist = forall a. Exist a > > bottom (Exist (_ :: t)) = Exist (undefined :: t) gives me the error Inferred type is less polymorphic than expected Quantified type variable `a' is unified with `t' When checking a pattern that binds In an equation for function `bottom': bottom (Exist (_ :: t)) = Exist (undefined :: t) I can work around this, as follows: > bottom' (Exist x) = case x of {(_::t) -> Exist (undefined :: t)} but it is annoying. The second case may have to do with context reduction. Consider > class Silly a b > > data Exist a = forall t. Silly a t => Exist t > > data Id x = Id x > instance (Silly a b) => Silly a (Id b) > > applyId (Exist x) = Exist (Id x) This gives me /tmp/t.hs:8: Could not deduce `Silly a1 t' from the context (Silly a t) Probable fix: Add `Silly a1 t' to the the existential context of a data constructor arising from use of `Exist' at /tmp/t.hs:8 in the definition of function `applyId': Exist (Id x) although the instance declaration does guarantee the program is type correct. I can fix this by adding a functional dependency: > class Silly a b | b -> a but this is again annoying. Am I expecting too much from the type checker? Thanks, Dylan Thurston

1 0

RE: Release schedule for GHC 5.02
by Simon Marlow 20 Aug '01

20 Aug '01

> I can use a term sharing garbage collector, > but is that what you mean with compacting ? > For example, given the datatype: > > data T = N T T > | L > > And the following graph before collection: > > N > / \ > N N > / \ / \ > L L L L > > Will this result in the graph below after > compacting garbage collection ? > > N > / \ > \ / > N > / \ > \ / > L No, it simply means that the heap is compacted in-place rather than the live data copied into new memory and the old memory discarded. The former is normally called "in-place compaction", "mark-compact", or just "compaction", the latter is normally called "two-space" or "copying" collection. In-place compaction is somewhat slower than copying, but doesn't require any extra memory at garbage collection time, apart from some extra space to store a bitmap - ie. 1/32 of the heap size on a 32-bit machine. Cheers, Simon

1 0