[ghc-steering-committee] Constructor synonyms, signatures on pattern synonym constructors

[Simon Peyton Jones]

Some thoughts



·         To me it's clear that we should abandon #41 in favour of #42.  Indeed the author did so himself, but then re-opened it saying only "@kosmikus thinks this should be reopened".



I could elaborate, but see the discussion on #41. I think it’s pretty much a consensus.



·         For #42, I’m mildly in favour, as I said on the thread. (But no holes please!)



·         I agree with Roman that that type of the constructor should be the same as that of the pattern, constrains aside.  We can always loosen later if there is well-supported evidence that doing so would be good.



Simon







|  -----Original Message-----

|  From: ghc-steering-committee [mailto:ghc-steering-committee-

|  bounces at haskell.org] On Behalf Of Christopher Allen

|  Sent: 21 March 2017 05:55

|  To: ghc-steering-committee at haskell.org

|  Subject: [ghc-steering-committee] Constructor synonyms, signatures on

|  pattern synonym constructors

|

|  I’m shepherding this two intertwined proposals, the Github discussions

|  are located at:

|

|  - https://github.com/ghc-proposals/ghc-proposals/pull/41

|  - https://github.com/ghc-proposals/ghc-proposals/pull/42

|

|  The rendered proposals are located at time of review at:

|

|  - https://github.com/treeowl/ghc-<https://github.com/treeowl/ghc-proposals/blob/680d909a07b10b6a37a64adf174ee845783dc2a4/proposals/0000-constructor-synonyms.rst>

|  proposals/blob/680d909a07b10b6a37a64adf174ee845783dc2a4/proposals/0000<https://github.com/treeowl/ghc-proposals/blob/680d909a07b10b6a37a64adf174ee845783dc2a4/proposals/0000-constructor-synonyms.rst>

|  -constructor-synonyms.rst<https://github.com/treeowl/ghc-proposals/blob/680d909a07b10b6a37a64adf174ee845783dc2a4/proposals/0000-constructor-synonyms.rst>

|  - https://github.com/treeowl/ghc-<https://github.com/treeowl/ghc-proposals/blob/559df2865db8e4427b1f24d3100e59d61cb60e54/proposals/0000-bidir-constr-sigs.rst>

|  proposals/blob/559df2865db8e4427b1f24d3100e59d61cb60e54/proposals/0000<https://github.com/treeowl/ghc-proposals/blob/559df2865db8e4427b1f24d3100e59d61cb60e54/proposals/0000-bidir-constr-sigs.rst>

|  -bidir-constr-sigs.rst<https://github.com/treeowl/ghc-proposals/blob/559df2865db8e4427b1f24d3100e59d61cb60e54/proposals/0000-bidir-constr-sigs.rst>

|

|  Very briefly,

|

|  Proposal #41 is constructor synonyms. This would allow users to define

|  variables with capitalized names and operators that begin with colons.

|  They are meant to complement pattern synonyms. This example from the

|  rendered proposal captures the idea and complementarity well I think:

|

|

|  pattern NF :: a -> NF a

|  pattern NF a <- UnsafeNF a

|

|  constructor NF :: NFData a => a -> NF a

|  constructor NF a = a `deepseq` UnsafeNF a

|

|  pattern Zero :: (Eq a, Num a) => a

|  pattern Zero <- ((== 0) -> True)

|

|  constructor Zero :: Num a => a

|  constructor Zero = 0

|

|  Proposal #42 would add type signatures for bidirectional pattern

|  synonym constructor functions. Currently we can write this:

|

|  pattern Zero :: (Num a, Eq a) => a

|  pattern Zero <- ((== 0) -> True)

|    where

|      Zero = 0

|

|  Per Feuer:

|

|  >The trouble in this case is that the Eq constraint from the pattern

|  "infects" the constructor. So if I have a number type I can't test for

|  equality, I can't use Zero to construct it.

|

|  It would permit writing things like this instead:

|

|  pattern Zero :: (Eq a, Num a) => a

|  pattern Zero <- ((== 0) -> True) where

|    Zero :: Num a => a -- optional

|    Zero = 0

|

|  This would prevent the pattern’s Eq constraint from “infecting” using

|  Zero as a constructor, which doesn’t actually need Eq.

|

|

|  — My thoughts follow —

|

|  I think Richard’s right about how we’ll need to handle compatibility.

|  I agree that the current warnings policy is a bit restrictive but it’s

|  not worth getting people riled up over it.

|

|  I agree with Simon's comment on #42. I think we need to take seriously

|  whether or not this proposal compromises the use-case of the naïve

|  user consuming a library API that uses pattern constructors. Partly

|  why I feel this is important is that as much debate as it draws,

|  Haskell users consuming a lens-based API are able to cargo cult and

|  move on with what they’re doing. I think pattern constructors should

|  be held to a higher usability standard than lens due to looking like

|  data constructors and being baked into the implementation.

|

|  This seems to clear up a limitation in expressiveness with few

|  downsides as long as we avoid using holes and respect the community’s

|  desires on backwards compatibility. Avoiding holes should make

|  implementation easier and have fewer unpredictable behaviors down the

|  road as well.

|

|

|  — My recommendation for the proposal —

|

|  My recommendation is that we accept both proposals. My reservation

|  would be that it shouldn't have serious downsides for the existing

|  users of pattern synonyms, be they authors or consumers.

|

|

|  Cheers,

|  Chris

|  _______________________________________________

|  ghc-steering-committee mailing list

|  ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>

|  https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-<https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

|  committee<https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170322/b096f69b/attachment-0001.html>