> On Dec 29, 2021, at 1:19 PM, Edward Kmett <ekm...@gmail.com> wrote: > > If this is just about GHC internals, then by all means carry on.
Yes, I should have clarified: this is just and solely about GHC internals! I have no designs on suggesting a wider convention like this. Indeed, both of the designs you describe below make great sense to use pattern synonyms for -- and without any herald that you are doing so. Within GHC, however, we now have a few cases where pattern synonyms are effectively behaving like or-patterns, which I find unexpected and confusing without a marker telling me Something Unusual is going on. (Why? Because in both cases, the pattern synonym is really designed to act like a constructor. In the first case, if I understand correctly, the pattern synonym is just a renaming of an existing constructor, with no extra computation. In the second case, if I understand correctly, the pattern synonym captures what used to be a constructor. It's plausible that GHC will want to adopt either of these patterns at some point in the future, but we do not do either one today, and so I would say to address any change to my proposed coding convention when this happens.) Richard > > -Edward > > On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett <ekm...@gmail.com > <mailto:ekm...@gmail.com>> wrote: > Please no. > > 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. > > 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. > > All the existing pattern constructors in the lens library would fail either > bar. > > So I have to say, either of these would probably destroy every use of pattern > synonyms I use today. > > -Edward > > On Wed, Dec 29, 2021 at 11:55 AM Richard Eisenberg <li...@richarde.dev > <mailto:li...@richarde.dev>> wrote: > Hi devs, > > 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 new pattern synonym > <https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7261/diffs#7dcf5b567a6cd3c9d98cf8d57323fbca1b1536e9_1128_1130> > that caught me off-guard. > > So, I'd like to propose the following convention: Every pattern synonym > satisfies one of the following two criteria: > 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. > 2. The pattern synonym begins with the prefix `PS_`. > > 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. > > 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. > > Future IDE support that could, say, color pattern synonyms differently to > regular constructors would obviate the need for this convention. > > 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. > > Thanks! > Richard > _______________________________________________ > ghc-devs mailing list > ghc-devs@haskell.org <mailto:ghc-devs@haskell.org> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > <http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs>
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
