| > g = \x::(Int,Bool) -> let-type (a,b) = (Int,Bool) in e | > | > But notice that the RHS of a pattern-matching let-type is | statically | > guaranteed to have the right shape. So I don't allow | > | > let-type (a,b) = c in ... | > | > (where c is a type variable). | | Really? I disagree. Making pattern type sygnatures perform | unification of the variable with the supplied signature is | useful for resolving ambiguities, and backward-compatible | (valid programs will remain valid), and doesn't allow | "unwanted generality" to cause trouble (when an expression | has a more general type than needed). I was meaning in the translation into System F of the program. Under my proposal (= yours) if one writes f (x::(a,b)) = e then f is forced to have type f :: (T1, T2) -> ... for some T1, T2. In saying that let-type can't pattern-match against a type variable c, I'm just saying that f cannot have type f :: forall c. c -> .... I think I just didn't express myself well enough. Simon
Tue, 8 May 2001 08:25:39 -0700, Simon Peyton-Jones <simonpj@microsoft.com> pisze:
I was meaning in the translation into System F of the program. [...]
Ah, OK, sorry. More strange behavior of Hugs (none of this is allowed by ghc): \(x :: a) (y :: b) -> x+y -- not allowed \(x :: a) -> \(y :: b) -> x+y -- allowed f :: Int->Int->Int; f x = \(y::a) -> x+y -- not allowed f :: Int->Int->Int; f = \x (y::a) -> x+y -- allowed I guess that the constraint that a type is not more specific than a pattern type signature tells is checked once at some point of time. It is rejected only when the type inference determined the more specific type before this check was performed, but it might be determined later which is not caught. I would remove the check altogether. -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK
participants (2)
-
Marcin 'Qrczak' Kowalczyk -
Simon Peyton-Jones