<div dir="ltr">If this is just about GHC internals, then by all means carry on.<div><br></div><div>-Edward</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett <<a href="mailto:ekmett@gmail.com">ekmett@gmail.com</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"><div dir="ltr"><div>Please no.</div><div><br></div><div>I use them to pun constructors between multiple types that will be in scope at the same time, (e.g. when I have 8 Var constructors on different types in scope between my core language term language and type language...) and often overload them on classes. I can't write the pragma, and the PS_ destroys any utiity I get from any common name.<br></div><div><br></div><div>I use them as a migration guide, when I add functionality. PS_ destroys that usecase, but then COMPLETE pragmas are a hacky mess in their current state and often simply can't be applied.</div><div><br></div><div>All the existing pattern constructors in the lens library would fail either bar.</div><div><br></div><div>So I have to say, either of these would probably destroy <i>every</i> use of pattern synonyms I use today.</div><div><br></div><div>-Edward</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec 29, 2021 at 11:55 AM Richard Eisenberg <<a href="mailto:lists@richarde.dev" target="_blank">lists@richarde.dev</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"><div>Hi devs,<div><br></div><div><div>Maybe I'm just old fashioned, but I've come to find pattern synonyms really confusing. Because pattern synonyms will tend to appear next to proper data constructors in code (and they look just like data constructors), when I see one, I think it *is* a data constructor. This problem was motivated by a recent MR that introduces a <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7261/diffs#7dcf5b567a6cd3c9d98cf8d57323fbca1b1536e9_1128_1130" target="_blank">new pattern synonym</a> that caught me off-guard.</div><div><br></div><div>So, I'd like to propose the following convention: Every pattern synonym satisfies one of the following two criteria:</div><div>1. The pattern synonym is a member of a set of synonyms/constructors that expresses a view of a type. There would naturally be a `COMPLETE` pragma including the set. `GHC.Types.Var.Inferred` is an example.</div><div>2. The pattern synonym begins with the prefix `PS_`.</div><div><br></div><div>In the end, I'd probably prefer just (2). With Inferred, for example, I've been caught in the past trying to figure just what the constructors of ArgFlag were (there seemed to be too many), until I realized what was going on.</div><div><br></div><div>Pattern synonyms are useful abstractions. I like them. But my mental model of a pattern match is that it matches the structure of the scrutinee and performs no computation. Pattern synonyms violate both of these assumptions, and so (as a reader) I like to know when to put these assumptions to the side.</div><div><br></div><div>Future IDE support that could, say, color pattern synonyms differently to regular constructors would obviate the need for this convention.</div></div><div><br></div><div>What do others think here? `PS_` is ugly. I don't need something quite so loud and ugly, but it's also easy to remember and recognize.</div><div><br></div><div>Thanks!</div><div>Richard</div></div>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
</blockquote></div>