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
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