- Glasgow-haskell-users

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

RE: GHC Library Documentation
by Simon Marlow 16 Aug '01

16 Aug '01

> The GHC library documentation at > <http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html> > seems to > have a lot missing: > > * certain modules such as MonadError There isn't any documentation for these Monad libraries that I'm aware of. Of course when HaskellDoc is up and running we'll have auto-generated documentation, but until then... > * the 'std' category > * the Prelude 'std' just contains the Prelude and standard libraries, and a bunch of GHC-specific stuff that isn't intended for external consumption. The Prelude and standard libraries are documented in the report and library report respectively (and GHC is pretty ruthless about not exporting extra stuff from these libraries, so the Haskell 98 documentation should be accurate). When we switch over to the new library scheme and get HaskellDoc going, we'll be able to do a much better job here. Cheers, Simon

1 0

GHC Library Documentation
by Ashley Yakeley 16 Aug '01

16 Aug '01

The GHC library documentation at <http://www.haskell.org/ghc/docs/latest/set/book-hslibs.html> seems to have a lot missing: * certain modules such as MonadError * the 'std' category * the Prelude Are there plans to update this, or am I looking in the wrong place? The Library Report sort of covers the 'std' category, though not to the same level of detail, but I can't find anything useful on the Prelude. -- Ashley Yakeley, Seattle WA

1 0

Re: GHCi grumbles (4)
by Alex Ferguson 15 Aug '01

15 Aug '01

George Russell: > 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. Do the GHC Team have > anything to suggest for dealing with this problem? Doubtless due to some _fiendishly_ clever static analysis going on in the background? And let's face it, GQT (and arguably R4 in general) is definitely "background". ;-) Cheers, Alex.

1 0

Re: GHCi grumbles (2)
by Marcin 'Qrczak' Kowalczyk 15 Aug '01

15 Aug '01

Wed, 15 Aug 2001 17:33:02 +0100, Simon Marlow <simonmar(a)microsoft.com> pisze: > It's hard to do, unless you adopt a policy such as ending the current > input with ';', which doesn't seem terribly attractive. The right way > to do it is for the parser to be incremental and interact with readline, > but I can't see an easy way to do that. And it's not clear when a multi-line expression ends, e.g. case foo of 1 -> xxx 2 -> yyy 3 -> zzz Python uses the convention that an empty line entered interactively ends a multiline statement. Its syntax is different from Haskell in that it can be determined when a statement is multiline from the first line, and that it's not possible to write certain statements in a single line - so for Python it's more important to be able to enter multiline statements. What is a pain in Python: repeating a whole multiline statement (because, say, of an error in the middle made previously) requires bringing each line from history separately. Some Unix shells are different and bring the whole multiline statement from the history, providing a substitute of a full-screen editor, with the main surprises being that Enter executes the statement and up/down arrows typically don't work either. In zsh pressing End at the end of a line, or Home at the beginning, allows to go up and down through lines, and Alt-Enter or Ctrl-V Ctrl-J allow to insert a newline character. -- __("< Marcin Kowalczyk * qrczak(a)knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK

1 0