#10928: Refine pattern synonym sigantures -------------------------------------+------------------------------------- Reporter: mpickering | Owner: Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Compiler | Version: 7.10.2 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | -------------------------------------+-------------------------------------
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.
This is copied from a message sent to ghc-devs. This ticket is to track the progress. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/10928 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler