Re: Pattern Synonym Signature Confusion

3 Oct 2015

      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  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
 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
 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@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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs