<div dir="ltr"><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Cheers</div><div>Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Feb 2019 at 02:39, Eric Seidel <<a href="mailto:eric@seidel.io" target="_blank">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">In <a href="https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0008-type-infix.rst</a> we already have an approved alternative: "value".<br>
<br>
On Sun, Feb 3, 2019, at 17:50, Joachim Breitner wrote:<br>
> Hi,<br>
> <br>
> Am Sonntag, den 03.02.2019, 10:45 -0500 schrieb Eric Seidel:<br>
> > I'm more bothered by the fact that the data/constructor tag has now<br>
> > become 'pattern', which feels to me like it should only apply to<br>
> > pattern synonyms. But according to <br>
> > <a href="https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-425736470" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/167#issuecomment-425736470</a><br>
> > it sounds like that ship may have sailed already if we want to be<br>
> > consistent (which we should!).<br>
> <br>
> We can maybe fix it consistently, and phase out “pattern” (make it an<br>
> alias for whatever we choose) … but do we have an obviously appropriate<br>
> name?<br>
> <br>
> Cheers,<br>
> Joachim<br>
> <br>
> -- <br>
> Joachim Breitner<br>
>   <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
>   <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
> <br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> Email had 1 attachment:<br>
> + signature.asc<br>
>   1k (application/pgp-signature)<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>