Concrete syntax for pattern synonym type signatures

[Richard Eisenberg]

Let me restate the proposals more concretely. Correct me if I'm wrong!

Suppose we have the following declarations:

   data T a b where
     MkT :: (Eq a, Ord b, Show c) => a -> (b, b) -> c -> T a b

   pattern P x y = MkT 5 (y, True) x

What is the type of P?

Simon's proposal:

> pattern P :: (Eq a, Ord Bool, Show c) => (Num a) => c -> Bool -> T a Bool

Or, more generally:

> pattern <pat> :: <provided constraints> => <required constraints> => <matched args> -> <result type>


My proposal:

> pattern P :: (Num a) => (Eq a, Ord Bool, Show c) => c -> Bool -> T a Bool

Or, more generally:

> pattern <pat> :: <required constraints> => <provided constraints> => <matched args> -> <result type>

The only difference is the order of required vs. provided constraints.


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.

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