Concrete syntax for pattern synonym type signatures
Simon Peyton Jones
simonpj at microsoft.com
Tue Nov 11 17:48:55 UTC 2014
| 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.
| On Nov 10, 2014, at 4:07 PM, Simon Peyton Jones
| <simonpj at microsoft.com> wrote:
| > | Whatever syntax we choose, I would highly recommend putting in a
| > | helpful link to more information in error messages.
| > In principle I like this very much, but I have always stumbled on
| > - writing links that will remain stable for ever (and are hence
| > release-specific)
| > - keeping them up to date when the version changes
| > - making them easy to test e.g. in my build tree
| > Separate question really, but would need some systematic attention
| to make it work properly in general.
| Is there a way of pulling the version from DynFlags? If so, it would
| be easy to include the version number in an SDoc. Then, we could make
| the link go to the user manual. It would be easy to write a function
| `userManualLink :: String -> SDoc` that takes the last bit of the link
| and produces a link to the manual for the version at hand. (It
| wouldn't work for non-released versions, but I'm OK with that.)
More information about the ghc-devs