Re: ghc-4.02 crashes with Windows NT - followup
Meurig Sage wrote: Hi, I'm using ghc-4.02 on Windows NT. I downloaded the binary installshield and the cygwin B20.1. I then compiled up a large program. The compiled program crashes some of the time with the following error: ... This problem goes away if I increase the heap size sufficiently with -H. So it looks like its another garbage collector bug. As a quick follow up, I should have said. The same program runs fine with ghc-4.02 under linux. Meurig -- Meurig Sage Dept of Computing Science University of Glasgow http://www.dcs.gla.ac.uk/~meurig mailto:[EMAIL PROTECTED]
Re: Haskell 2 -- Dependent types?
On 25-Feb-1999, Carl R. Witty [EMAIL PROTECTED] wrote: Fergus Henderson [EMAIL PROTECTED] writes: Certainly a language with dependent types should define exactly what types the type checker will infer. But when generating code, the compiler ought to be able to make use of more accurate type information, if it has that information available, wouldn't you agree? I think it would be most unfortunate if simply adding more accurate type information could change a program's behaviour. I'm not sure if that last sentence refers to 1) the compiler inferring more accurate type information or 2) the user adding a more accurate type declaration. I meant it to refer to both. 1) There's a word for "optimizers" that change the meaning of a program (in ways not allowed by the language spec); that word is "buggy". Sure. But it would be a little unfortunate if compilers had to keep around two sets of type information, one being the types that the language specification required that it infer, and the other being the (potentially more accurate) set of types that it was able to infer after inlining etc. It would be nicer if compilers could just use the most precise types and be guaranteed that the extra precision wouldn't affect the semantics. However, this is a less important point than the one below. 2) Yes, I agree that the possibility that user-supplied type declarations can change the meaning of the program is a strike against the idea. -- 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: monomorphism ...
John Hughes : Everybody agrees the monomorphism restriction is a pain: ... So, let's make it visible, in the simplest possible way. Let there be TWO forms of binding: x = e, and x := e (say). A binding of the form `x = e' is interpreted using call-by-name, and may of course be overloaded: ... Can somebody comment on the relation between this, and the protocols used in Concurrent Clean (with their =, =, and =:)? Jerzy Karczmarczuk Caen, France.
Re: Haskell 2 -- Dependent types?
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. Besides, Haskell had polymorphic recursion even before the rule about a type signature making it possible to make functions polymorphically recursive. It was just more tedious to write it before. 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? -- Lennart
Re: Haskell 2 -- Dependent types?
The key issue in Lennart's example, I think, is monomorphic recursion. For the function f _ = let y = f 'a' in undefined Haskell incorrectly (IMHO) infers the type `f :: Char - a' instead of the more general type `f :: b - a'. 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. Interestingly, the Mercury typechecker behaves differently for the equivalent example: it infers the more general type. I consider the fact that you can construct examples like the one that Lennart showed to be a wart in Haskell, and I'm quite pleased that Mercury doesn't exhibit the same wart. On a related topic, I think there's nothing wrong with having a type system in which some expressions don't have a principle type. However, in such situations, where there is no type declaration and there is no principle type, then I think the type checker ought to complain of ambiguity rather than going ahead and inferring a type which might be too specific. If the type inference always infers the most general type, or complains of ambiguity if it can't, then it's possible to preserve the desirable property that adding type declarations won't change the program's behaviour. -- 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.
