convention around pattern synonyms

Edward Kmett ekmett at
Wed Dec 29 18:19:51 UTC 2021

If this is just about GHC internals, then by all means carry on.


On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett <ekmett at> 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 <lists at>
> 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
>> <> 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 at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list