Hallo again. Supposing that (some version of) Haskell had first class modules, and type variables could be universally quantified at the module level, would rule 2 of the monomorphism restriction go away? Is this among the aims of the "First-class modules for component-based programming" (proposal document by Simon Peyton Jones and Mark Jones, 1996) research project? Regards, Tom
On 07-Nov-2000, Tom Pledger <Tom.Pledger@peace.com> wrote:
Supposing that (some version of) Haskell had first class modules, and type variables could be universally quantified at the module level, would rule 2 of the monomorphism restriction go away?
No. | Rule 2. Any monomorphic type variables that remain when type | inference for an entire module is complete, are considered | ambiguous, and are resolved to particular types using the | defaulting rules (Section 4.3.4). Although this rule refers to the "entire module", its typical for the ambiguity to arise within a single function: foo = show (read "whatever") This expression is fundamentally ambiguous unless you somehow disambiguate what type it is that you are trying to read. I don't see how first class modules could solve that. -- Fergus Henderson <fjh@cs.mu.oz.au> | "I have always known that the pursuit | of excellence is a lethal habit" WWW: <http://www.cs.mu.oz.au/~fjh> | -- the last words of T. S. Garp.
Fergus Henderson writes:
On 07-Nov-2000, Tom Pledger <Tom.Pledger@peace.com> wrote:
Supposing that (some version of) Haskell had first class modules, and type variables could be universally quantified at the module level, would rule 2 of the monomorphism restriction go away?
No.
| Rule 2. Any monomorphic type variables that remain when type | inference for an entire module is complete, are considered | ambiguous, and are resolved to particular types using the | defaulting rules (Section 4.3.4).
Although this rule refers to the "entire module", its typical for the ambiguity to arise within a single function:
foo = show (read "whatever")
This expression is fundamentally ambiguous unless you somehow disambiguate what type it is that you are trying to read. I don't see how first class modules could solve that.
Thanks for the analysis. I see how there's no way for another module (or any other declarations in the same module) to disambiguate that. How about the cases where the module boundary plays a part in triggering the MR, like this? module MRDemo where x = return () I've got the impression that these cases are the ones which provoke most of the MR criticism. Would they be relieved by quantifying at the module level, so that the ambiguity gets passed to modules which import MRDemo and use x? Regards, Tom
participants (2)
-
Fergus Henderson -
Tom Pledger