Concrete syntax for pattern synonym type signatures

[Simon Peyton Jones]

|  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
|  <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.)
|  
|  Richard