The point of "pattern" (I believe) is that we want it to be invisible to the importer whether a constructor name was declared as a pattern synonym or a real data constructor, to allow abstraction and smooth migration of APIs when the concrete representation of a datatype changes. However, it would also make sense to allow "data" instead of "pattern", with exactly the same meaning (import either a data constructor or a pattern synonym with the given name). I wonder why we didn't do that. On this proposal, I think the named, standalone variant is preferable to the positional variant if we choose only one, because it allows more flexibility. Although I could imagine both being useful. Cheers Simon On Mon, 4 Feb 2019 at 02:39, Eric Seidel <eric@seidel.io> wrote:
In https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-ty... we already have an approved alternative: "value".
On Sun, Feb 3, 2019, at 17:50, Joachim Breitner wrote:
Hi,
Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel:
I'm more bothered by the fact that the data/constructor tag has now become 'pattern', which feels to me like it should only apply to pattern synonyms. But according to
https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-4257364...
it sounds like that ship may have sailed already if we want to be consistent (which we should!).
We can maybe fix it consistently, and phase out “pattern” (make it an alias for whatever we choose) … but do we have an obviously appropriate name?
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee Email had 1 attachment: + signature.asc 1k (application/pgp-signature)
ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee