Pattern Synonym Signature Confusion

Matthew Pickering matthewtpickering at
Thu Oct 1 11:23:15 UTC 2015

I think that the current state of pattern synonym signatures is quite
confusing, especially regarding the constraints. For those unfamiliar,
a signature looks like the following,

pattern ExNumPat :: (Show b) => (Num a, Eq a) => b -> T a

The first constraint being the "provided constraints" and the second
the "required constraints".

My main concern is when only a single constraint is specified then
these are treated as the provided constraints. The manual gives the
reason that this is the "more common" choice. It seems that this
motivation is driven by the original ticket which had a lengthy
discussion about GADTs. In my experience, the opposite is true, it is
more common to have required constraints.

This is true especially in a few common cases such as "pattern Foo =
27", where users define pattern synonyms which have (overloaded)
literals on the RHS. The most general signature for such a pattern is
"pattern :: () => (Eq a, Num a) => a".

For this reason, I think it would be better if either

1. Only specifying one constraint corresponded to the required constraints
2. We required users to specify both sets of constraints, even if the
provided constraints are empty.

In terms of breakage, I don't think that pattern synonym signatures
are widely used yet. In both schemes it is possible to write backwards
compatible code by writing both sets of constraints.

I think a lot of the confusion also arises from the unusual form of
the signature, it is unusual to specify two sets of constraints and I
suspect users tends to assume that a single set of constraints is
either provided or required depending on what they want it to mean.
Forcing the specification of both, forces the user to make the
distinction earlier rather than trying to decipher error messages.



More information about the ghc-devs mailing list