convention around pattern synonyms

[Edward Kmett]

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

-Edward

On Wed, Dec 29, 2021 at 12:19 PM Edward Kmett <ekmett at 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 <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/3f15de79/attachment.html>