[GHC] #10928: Refine pattern synonym signatures

[GHC]

#10928: Refine pattern synonym signatures
-------------------------------------+-------------------------------------
        Reporter:  mpickering        |                Owner:
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.10.2
      Resolution:                    |             Keywords:
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Other             |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
-------------------------------------+-------------------------------------
Description changed by simonpj:

Old description:

> > 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.

New description:

 > 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#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler