Hello,
On Sat, 31 Oct 2020 18:01:16 +1000
Nick Coghlan
On Sat, 31 Oct 2020 at 17:49, Paul Sokolovsky
wrote: Alternatively, can add "inline guard sigils" for the most common guard conditions, which would be equality, period:
match r: case (src, None): case (==c, msg): case (==s, msg):
`==` interacts poorly with other aspects of the pattern syntax (most notably keywords in class patterns), but PEP 642's identity constraint expressions would allow:
Nice to hear that there're (high-hierarchy) people who want to do 2nd round on intent-explicitizing sigils, thanks. I blame it on my Saturday's hazy mind, but also for the interest of other readers, could you elaborate on "`==` interacts poorly with other aspects of the pattern syntax"? To elaborate from my side, I'm talking about introducing unary prefix operator "==". That should be pretty disambiguated on its own. (Of course, such an operator would be allowed only in the expression syntax for the "case" clause. The biggest risk my hazy mind sees is founding fathers' fixation with doing any grammar disambiguation on the level of the (flat) grammar, which leads to atrocious grammars. Whereas a practical person would just go for a level-above check).
match r: case (src, ?is None): ... # Any src, msg is None case (?is c, msg): ... # Any msg, src is c case (?is s, msg): ... # Any msg, src is s
So, you're talking about introducing unary prefix operators "?" and "?is". And while "?is" is clear (though not pretty), I don't see how the syntax of "?" translates to the meaning you assign to it, "lookup value of". (Btw, just thought, unary "+" could be used for "value lookup" syntax. At least, with such usage, it will be "mathematically understandable". Actually, would anything need to be done at all to use unary "+" in this meaning? Hmm, someone must have thought about that before...)
Cheers, Nick.
-- Best regards, Paul mailto:pmiscml@gmail.com