| My proposal:
|
| > pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a
| > Bool
|
| My previous comment about bizarre scoping is that the universal
| variables -- which (in my opinion) go with the required constraints --
| scope over both sets of constraints. The existential variables go with
| the provided constraints and scope over only the provided constraints.
| So, Simon's ordering means that the scope of the second (lexically)
| listed constraints have a *smaller* scope than the first listed
| constraints. With my ordering, the size of the scope increases as you
| read to the right, as it normally does.
I _think_ you mean that you _could_ write P's type like this:
| > pattern P :: forall a. (Num a) =>
forall c. (Eq a, Ord Bool, Show c) =>
c -> Bool -> T a
I'm not sure we really would give it that nested structure, but it would be reasonable to do so.
Richard's point is that the match-required constraints can *only* mention the universally quantified type variables.
So yes, I think Richard is probably right.
Incidentally ote that
pattern P x = (3,x)
would have type
pattern P :: Num a => () => b -> (a,b)
But since the "match-provided but no match-required" case must look simple, the "match-required but no match-provided" case is bound to look odd.
OK, Gergo, I think you are good to go now.
Simon
| On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones
|