On Dec 29, 2021, at 1:19 PM, Edward Kmett 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 mailto:ekmett@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 mailto:lists@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#7dcf5b567a6cd... 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

I agree that this kind of backward-compatibility pattern synonym is good and shouldn't be prefixed with PS_. But do you have a concrete example of this leakage of an internal GHC type via TH? While I can imagine this happening, I don't know of any examples in practice. Note that even enumeration types (like Role) have separate TH counterparts. Richard

On Dec 29, 2021, at 6:12 PM, Viktor Dukhovni wrote:

Some "GHC-internal" types leak to users via TH, and their constructors occasionally pick up new fields, causing breakage downstream. The extra field often has a sensible default (Nothing, [], ...) and it should be best practice to rename the constructor when adding the new field, while replacing the original constructor with a pattern synonym with the "old" signature.

data Foo = ... | NewImprovedMkFoo X Y Z -- was MkFoo Y Z

pattern MkFoo :: Foo pattern MkFoo Y Z = NewImprovedMkFoo Nothing Y Z

When pattern synonyms are used to maintain a backwards-compatible API, there should of course be no special signalling to differentiate them from "real" constructors.

The boundary between "GHC-internal" and external may not always be obvious, some care is required to reduce leaking breakage via TH.

-- Viktor. _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

On Dec 30, 2021, at 3:25 PM, Viktor Dukhovni wrote:

Perhaps my assumption that TH types directly mirror the internal AST is not correct... A recent user-visible change is in `ConP`

Many TH types are modeled after GHC-internal types, but this is just a matter of convenience, not necessity. (The necessity -- if we are to maintain feature parity in TH -- is that the same information is representable in both sets of types, not that the representations are the same.) So the convention I'm proposing here wouldn't affect TH. Richard