convention around pattern synonyms

[Edward Kmett]

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 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 at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20211229/9c4b0646/attachment.html>