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
_______________________________________________
ghc-devs mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/ghc-devs
