- Glasgow-haskell-users

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

Release schedule for GHC 5.02
by Julian Seward (Intl Vendor) 20 Aug '01

20 Aug '01

Greetings, GHC users and developers. We're hoping to ship GHC 5.02 in about three weeks. The plan is as follows: * Fri 17 Aug (end of this week): feature freeze. * Monday 20 Aug - Friday 31 Aug: stabilise, bug fix. * Fri 31 Aug: release. GHC USERS: Soon after the feature freeze, maybe around 20 Aug, we plan to put out a release candidate. If you reported bug(s) in the past couple of months and are hoping that they are fixed in 5.02, please download and try the release candidate. We're making this candidate available early in the stabilisation period so as to give us a chance to fix issues before the final release. Do take this opportunity to work with us to improve the quality of the 5.02 release. GHC DEVELOPERS: please try and check in any final changes before Friday (or at least advise us of your intentions). Given that we're trying to stabilise GHC, the fewer changes you check in, the better. Below is a list of changes in 5.02 relative to 5.00.X. As ever, we welcome your feedback. J (the 5.02 release coordinator) ------------------------------------------------------------------------ - 5.02 will be released for x86-Linux, Sparc-Solaris and Win32. Compared to the 5.00.X series, 5.02 will contain the following user-visible major changes: * Many bug fixes and stabilisations in the interactive system. Includes a clone of the :i (info) command. * New compacting garbage collector, which reduces the total amount of memory needed to run progs at the expense of being a bit slower. The old GC is still there and still used by default. * Partial FFI implementation for the interpreter: foreign import {static, dynamic}. No foreign export or label. * Win32: simple one-click-install package. No requirement for Cygwin any longer, and you don't need to install any other supporting stuff either. Internal changes: * New demand analyser, hopefully generating better code. * Majorly rewritten I/O library. * Much heroic hacking by Ken Shan to revive the Alpha port. Probably lots of other stuff I've forgotten.

3 2

RE: MPI status?
by Simon Peyton-Jones 20 Aug '01

20 Aug '01

Duncan I don't know quite what the status of GPH, the parallel version of GHC, is. But there's a bunch of peopl who do, at gph(a)cee.hw.ac.uk. (eg. Phil Trinder, Hans Loidl.) The home page is http://www.cee.hw.ac.uk/~dsg/gph/ I'm copying them, so they can reply directly. Simon | -----Original Message----- | From: Duncan Coutts [mailto:dcoutts@cray.com] | Sent: 18 August 2001 23:52 | To: glasgow-haskell-users(a)haskell.org | Subject: MPI status? | | | 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 | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users(a)haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-| haskell-users |

1 0

ANN: linkchk-0.00 - a gtk based network link heartbeat monitor
by Jens-Ulrik Petersen 17 Aug '01

17 Aug '01

Hello, I am happy to announce the first release of linkchk, a small program whose sole job is simply to monitor a ping heartbeat between its host and a gateway (router) on a local network link. Sounds simple? Well it is really, except for some first hurdles of pipes, lazy fileRead'ing, etc. Source code and a Linux binary are available from <http://www.01.246.ne.jp/~juhp/haskell/linkchk/>. ghc and gtk+hs are required to build linkchk. This is the first Haskell program I am releasing on the net, so I would appreciate any feedback I can get whether it be in the form of comments on the code, questions, or patches. Happy pinging! Jens

1 0

Re: GHCi grumbles (4)
by Ashley Yakeley 16 Aug '01

16 Aug '01

At 2001-08-15 07:12, George Russell wrote: >If I run GHCi but leave it doing nothing and waiting for input, the process >nevertheless eats CPU time, and is at the moment bringing my RealAudio relay >of Gardeners' Question Time to a halt. Which platform are are your running this on? -- Ashley Yakeley, Seattle WA

2 2