Concrete syntax for pattern synonym type signatures

[Dr. ERDI Gergo]

Just a small note about parsing:

On Tue, 4 Nov 2014, Simon Peyton Jones wrote:

> The more I think about this, the more I think we'll just have to bite 
> the bullet and adapt the syntax for constraints in pattern types, to 
> distinguish the match-required and match-provided parts. Suppose we let 
> pattern signatures look like this:
>
>  pattern P :: forall tvs. (match-provided ; match-required) => tau
>
> The "; match-required" part is optional, and the "match-provided" part 
> might be empty.  So P1 and P2 would look like this:
>
>  pattern P1 :: forall a. (; Num a) => b -> (a,b)
>  pattern P2 :: forall a. (; Num a, Ord a) => a -> a
>
> Because the "match-required" part is optional (and relatively rare) the 
> common case looks just like an ordinary data constructor.

One thing worth noting is that implementing a parser for this would be far 
from straightforward, because currently contexts are parsed as types and 
then fixed up into contexts:

-- We parse a context as a btype so that we don't get reduce/reduce
-- errors in ctype.  The basic problem is that
--      (Eq a, Ord a)
-- looks so much like a tuple type.  We can't tell until we find the =>

So we would need to add a way of parsing (T1, T2, ..., Tn; U1, U2, ..., Um)
into a type, which would then require rejecting everywhere else where 
we really do mean a type... Sounds painful. Also painful: rewriting the 
whole context parsing code :/

Richard's suggestion:

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

has the nice property (unlike the current horrible syntax) that the 
foralls close left-to-right; also, it is very easy to parse :)

I'm hoping to see some more suggestions or general comments!

Bye,
 	Gergo