Oh gosh you are absolutely right. Ordinary, lexically scoped type variables only scope over the RHS of the relevant binding, not the body of the let. I was completely wrong about that.
In which case my objection is much milder: - the inconsistency of treatment wrt ordinary type variables (which require a forall; and yes, you can't give a forall for wildcards) - the lack of documentation The system would be simpler without this. So, is it really important? If so, we could add it later. Sorry to make such a misleading post. Simon | -----Original Message----- | From: [email protected] [mailto:[email protected]] | On Behalf Of Dominique Devriese | Sent: 05 February 2015 20:13 | To: Simon Peyton Jones | Cc: Thomas Winant; [email protected]; Frank Piessens | Subject: Re: Partial type sigs | | Simon, | | 2015-02-05 17:44 GMT+01:00 Simon Peyton Jones <[email protected]>: | > 3. It interferes with generalisation. | > | > For (3), consider | > | > let f :: _a -> _a | > | > f xs = reverse xs | > | > in (f True, f ‘x’) | > | > Here, f gets the type f :: forall b. [b] -> [b], and _a is unifed with | [b]. | > | > So it simply doesn’t make sense for _a to appear in the body. What | would it | > mean to say | > | > let f :: _a -> _a | > | > f xs = reverse xs | > | > in (f (True :: _a), f ‘x’) | | Isn't this a different case than Thomas' example? As I understand it, | an equivalent of his example would have the wildcard in scope in the | body of f, not in the body of the let. Something like this: | | let f :: _a -> _a | f xs = reverse (xs :: _a) | in (f [True], f "x") | | or | | let f :: _a -> _a | f xs = let ys :: _a | ys = tail xs | in reverse ys | in (f [True], f "x") | | I agree with what you say about _a being in scope in the body of the | if, but I don't see a problem with _a being in scope in the body of f. | Do you? | | Note also that I haven't yet checked which of both is actually | implemented. | | Regards, | Dominique _______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
