Pattern Synonym Signature Confusion

[Matthew Pickering]

I made a ticket[1] to track the progress of this issue. I agree that
the whole situation is confusing but I can't see anything much better.

[1]: https://ghc.haskell.org/trac/ghc/ticket/10928#ticket

On Sat, Oct 3, 2015 at 11:04 AM, Andres Loeh <mail at andres-loeh.de> wrote:
> Hi.
>
> Matthew, I'm in favour of your proposed change (probably slightly in
> favour of option 2 compared to option 1). I must say that the whole
> "double constraint" syntax is very confusing no matter what. If we
> could somehow find a better / more explicit way to specify provided
> constraints, that would be even better.
>
> Cheers,
>   Andres
>
> On Fri, Oct 2, 2015 at 1:58 PM, Matthew Pickering
> <matthewtpickering at gmail.com> wrote:
>> I have grepped the whole of hackage. There are only 10 pattern synonym
>> signatures in total in three separate packages (one of them being my
>> own). None of them specify provided constraints, three of them specify
>> required constraints. Of course this is a very small sample size but
>> it means that there wouldn't be any widespread breakage either way
>> with this proposal.
>>
>> ```
>> ../hackage-packages//ghc-exactprint-0.4.1.0/tests/examples/Sigs.hs:pattern
>> Single :: () => (Show a) => a -> [a]
>> ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern
>> Struct :: () => Struct t => SmallMutableArray# s Any -> t s
>> ../hackage-packages//structs-0/src/Data/Struct/Internal.hs:pattern Nil
>> :: forall t s. () => Struct t => t s
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> Ref' :: Path phi ix top -> HWithRef phi top ix
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> Const' :: forall top. Integer -> HWithRef AST top AExpr
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> BConst' :: forall top. Bool -> HWithRef AST top BExpr
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> And' :: forall top. HWithRef AST top BExpr -> HWithRef AST top BExpr
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> GT' :: forall top. HWithRef AST top AExpr -> HWithRef AST top AExpr
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> GT_0 :: Path AST top AExpr -> Path AST top BExpr
>> ../hackage-packages//transformations-0.2.0.0/examples/MultiRec.hs:pattern
>> Neg_0 :: Path AST top AExpr -> Path AST top AExpr
>> ```
>>
>> On Thu, Oct 1, 2015 at 10:48 PM, Simon Peyton Jones
>> <simonpj at microsoft.com> wrote:
>>> Matthew
>>>
>>> What you say sounds reasonable to me.  I certainly don't have a strong opinion that the current design is the "right" one.
>>>
>>> Simon
>>>
>>> | -----Original Message-----
>>> | From: ghc-devs [mailto:ghc-devs-bounces at haskell.org] On Behalf Of Matthew
>>> | Pickering
>>> | Sent: 01 October 2015 12:23
>>> | To: GHC developers
>>> | Subject: Pattern Synonym Signature Confusion
>>> |
>>> | 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.
>>> |
>>> | Thoughts?
>>> |
>>> | Matt
>>> | _______________________________________________
>>> | ghc-devs mailing list
>>> | ghc-devs at haskell.org
>>> | https://na01.safelinks.protection.outlook.com/?url=http%3a%2f%2fmail.haske
>>> | ll.org%2fcgi-bin%2fmailman%2flistinfo%2fghc-
>>> | devs&data=01%7c01%7csimonpj%40064d.mgd.microsoft.com%7c403e493d2a54438d264
>>> | 408d2ca52b5b9%7c72f988bf86f141af91ab2d7cd011db47%7c1&sdata=sjc2n0Gm1A%2ffe
>>> | OKEpntmEYqTfbYaLvk2sb%2b2vUqIqLU%3d
>> _______________________________________________
>> ghc-devs mailing list
>> ghc-devs at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs