Pattern Synonym Signature Confusion
matthewtpickering at gmail.com
Fri Oct 2 11:58:28 UTC 2015
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.
Single :: () => (Show a) => a -> [a]
Struct :: () => Struct t => SmallMutableArray# s Any -> t s
:: forall t s. () => Struct t => t s
Ref' :: Path phi ix top -> HWithRef phi top ix
Const' :: forall top. Integer -> HWithRef AST top AExpr
BConst' :: forall top. Bool -> HWithRef AST top BExpr
And' :: forall top. HWithRef AST top BExpr -> HWithRef AST top BExpr
GT' :: forall top. HWithRef AST top AExpr -> HWithRef AST top AExpr
GT_0 :: Path AST top AExpr -> Path AST top BExpr
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:
> What you say sounds reasonable to me. I certainly don't have a strong opinion that the current design is the "right" one.
> | -----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
More information about the ghc-devs