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