- Glasgow-haskell-users

MPI status?
by Duncan Coutts 24 Aug '01

24 Aug '01

Hi all, I'm doing an internship at Cray Inc this summer and I might get the opportunity of some computer time on a T3E machine. Now I am also a great Haskell fan and have been wondering about the possibility of getting parallel Haskell running on a real super-computer. I've read that someone is working on porting ghc's parallel features to an MPI implementation and also that someone recently got the alpha port working again. In case you don't know a T3E is a distributed memory alpha based super-computer. It supports MPI & pthreads. So my question is, what is the state of the art? What is the state of the MPI port? Does the alpha port work sufficiently well. One potential problem I can see is that I'm not sure gcc is avaliable on the T3E and I'm not sure how dependant ghc is upon the various GNU C extensions. So, if I can get an account, I'll have untill the end of September to test anything anyone can give me. You know they still program these machines in C, C++ & Fortran. Shocking! ;-) Duncan

7 7

Newbie: Mutable Arrays
by Saswat Anand 24 Aug '01

24 Aug '01

Hi, 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? Thanks, Saswat

2 1

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