When trying to compile the following module, ghc-3.02 dies with the
following message:
panic! (the `impossible' happened):
tcInstType:1
---
module Impossible where
type T a = Int
classC a where foo :: Int - IO a
instance C (T
Alastair Reid writes:
[redirected to [EMAIL PROTECTED]]
Arjan van Ijzendoorn (or is it Kees?) writes:
I've a complete program written using Haskell (GHC 3.02) but I'm unable to
load the program in Hugs (jan98, 1.4). I get an error that "showLitChar" is
not defined. I could try to
Guest account nr 2 writes:
Hi,
This is byron ([EMAIL PROTECTED]), and im at Chalmers this week,
where im having a problem getting GHC 2.10 to work. here is the error
msg:
ld: fatal: file simulate: cannot msync file; errno=49
do you have any ideas? what is msync?
If I remember
Hi,
This is byron ([EMAIL PROTECTED]), and im at Chalmers this week,
where im having a problem getting GHC 2.10 to work. here is the error
msg:
ld: fatal: file simulate: cannot msync file; errno=49
do you have any ideas? what is msync?
here is a full transcript:
In recent weeks we have been organising and polishing our locally
produced Haskell software. Most of this software was written for
educational purposes, but may be quite useful for a wider audience.
At: http://www.cs.ruu.nl/groups/ST/Software/index.html
you can find links and information
Alex,
If I were you I'd dispense with "deriving(Read,Show)" in module Publisher,
and add an explicit instance for Read/Show on Publisher in PublisherDB.
That would solve your circularity problem.
Haskell does permit mutually recursive modules, but Hugs does not support
them, and GHC requires
On Mon, 8 Jun 1998, S. Alexander Jacobson wrote:
1. it is not logically consistent to treat exceptions as return values
A function cannot do anything but return a value, can it?
For example, suppose that we define a new function:
foo' a b = a + b -- foo' is strict in its arguments
Alex Jacobson:
Ooops, I forgot to remove the "and". Anyway, my point is that
1. it is not logically consistent to treat exceptions as return values
2. as an implementation matter it violates laziness to do so
OK, now I follow. And diagree. ;-) On your second point first:
I'm not sure
