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
