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 <matthewtpicker...@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 > <simo...@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-boun...@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 _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
