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