RE: ghc-4.02 crashes with Windows NT - followup
As a quick follow up, I should have said. The same program runs fine with ghc-4.02 under linux. That's bizarre, because there's no architecture dependent code in the garbage collector except for the bit that allocates memory from the OS. Could you send us the code? Cheers, Simon
cvs version, PrelNumExtra fails to compile
I'm compiling the latest version (ie, cvs diff is silent). --- rm -f PrelNumExtra.o ; if [ ! -d PrelNumExtra ]; then mkdir PrelNumExtra; else find PrelNumExtra -name '*.o' -print | xargs rm -f __rm_food ; fi ; ../../../ghc/driver/ghc -recomp -cpp -fglasgow-exts -fvia-C -Rghc-timing -O -split-objs -odir PrelNumExtra -H30m -K2m -c PrelNumExtra.lhs -o PrelNumExtra.o -osuf o ghc: ignoring heap-size-setting option (-H20m)...not the largest seen NOTE: Simplifier still going after 4 iterations; bailing out. NOTE: Simplifier still going after 4 iterations; bailing out. CgHeapery.lhs:344: Non-exhaustive patterns in function mkRegLiveness gmake: *** [PrelNumExtra.o] Error 1 --- turning optimisation off allows the module to compile. Paul
Re: cvs version, PrelNumExtra fails to compile
Hello! On Sat, Feb 27, 1999 at 08:51:29PM +, P.C.Callaghan wrote: I'm compiling the latest version (ie, cvs diff is silent). The latter doesn't imply the first, as cvs diff (w/o any further options) diffs between the version your checkout is based on and your checkout itself. NOT: between current and your checkout! Regards, Felix.
Re: Haskell 2 -- Dependent types?
On 26-Feb-1999, Lennart Augustsson [EMAIL PROTECTED] wrote: This occurs because in the absense of type declarations, Haskell assumes that any recursion will be monomorphic, which is in general not necessarily the case. As I'm sure you know, type inference is in general impossible for polymorphic recursion, and since Haskell insists on decidable type checking this was an easy solution. Yep, there is a drawback to the Mercury approach, you lose decidability. But as we've been discussing losing decidability isn't necessarily such a bad thing ;-) Interestingly, the Mercury typechecker behaves differently for the equivalent example: it infers the more general type. Are you sure Mercury doesn't suffer from the same problem if you just complicate the example? Well, I'm fairly sure it doesn't, but I'm not completely 100% sure. -- Fergus Henderson [EMAIL PROTECTED] | "Binaries may die WWW: http://www.cs.mu.oz.au/~fjh | but source code lives forever" PGP: finger [EMAIL PROTECTED]| -- leaked Microsoft memo.
Re: Haskell 2 -- Dependent types?
On 25-Feb-1999, Lennart Augustsson [EMAIL PROTECTED] wrote: [someone wrote:] I've lost track of what we're talking about here. In what system can we not hope for principal types? [...] Cayenne doesn't have that property. Again, I think this is a feature, not a bug. I'll include a small example below. ... struct abstract type Stack a = List a push :: a - Stack a - Stack a push x xs = x : xs ... This has type sig type Stack a push :: a - Stack a - Stack a ... Outside the defining struct Stack is abstract and cannot be interchanged for List. But here's another type we could give push push :: a - List a - Stack which (outside the defining struct) would look like a totally different creature. So what does Cayenne do if you don't declare the type for `push'? Does it report an error? I agree that allowing this kind of thing is a feature, not a bug, so long as the compiler reports an error rather than inferring some (non-principle) type for cases like that where there is no principle type. The same issue with regard to principle types arises in Mercury with regard to the module system, since the Mercury module system allows synonym types to be exported as abstract types. Mercury sidesteps this by requiring explicit type declarations for any exported procedures. The original rationale for this requirement was that using explicit type declarations on interfaces is simply good software engineering practice, and that the presence of this requirement simplifies the implementation. I wasn't aware that this requirement is also essential for ensuring the existence of principle types. Haskell's module system of course does not allow synonym types to be exported as abstract types -- you have to use a newtype instead. However, this may be better than Mercury's approach, because abstract synonym types become second-class citizens once you add typeclasses, since (in both Haskell and Mercury) you're not allowed to have instance declarations for synonym types. -- Fergus Henderson [EMAIL PROTECTED] | "Binaries may die WWW: http://www.cs.mu.oz.au/~fjh | but source code lives forever" PGP: finger [EMAIL PROTECTED]| -- leaked Microsoft memo.
Re: Haskell 2 -- Dependent types?
So what does Cayenne do if you don't declare the type for `push'? Does it report an error? The basic principle in Cayenne is that you need type signatures everywhere. This is sometimes rather verbose and is relaxed in some cases, but not here. If you omit the type signature the compiler will complain. [... type signatures required for exported procedures...] I wasn't aware that this requirement is also essential for ensuring the existence of principle types. I think it depends on how you treat type synonyms. In Haskell they are true synonyms, and can always be expanded to a real type, which would be the principal type. But I really like type synonyms as abstract types, it's convenient. Haskell's module system of course does not allow synonym types to be exported as abstract types -- you have to use a newtype instead. However, this may be better than Mercury's approach, because abstract synonym types become second-class citizens once you add typeclasses, since (in both Haskell and Mercury) you're not allowed to have instance declarations for synonym types. Well, Cayenne doesn't have have type classes. :-) -- Lennart
