Hi Terry,
Thank you: I really like your wave/particules analogy. I think that
pattern matching is indeed uniting different concepts to build a
stronger, more versatile structure.
I also like your concept of a general "binding structure" with
different forms, such as assignment, parameter passing, and (according
to PEP 622) patterns. I feel that this categorisation puts pattern
matching quite in the correct place. Of course, there is also the
second aspect of "bind these variables---/if you can/" or "analyse and
compare the structure", which is the other part of this particule/wave
duality.
Concerning the guards (optional conditions), I also think that you
summarised very nearly. I tend to think of the patterns a bit like
the grammar of a programming language. Something that is supposed to
be static and declarative (as far as this is possible in Python).
Yet, some constraints in programming languages cannot be expressed by
a (context-free) grammar in a meaningful way. For instance, the
grammar itself does not keep you from having two parameters in a
function sharing the same name. This is a dynamic aspect, a
relationship between two otherwise independent parts of the overall
structure. And that is best caught by the guards. So, yes: as I see
it, the guards really add something that goes beyond the declarative
side of patterns. Hence, I completely agree with your characterisation.
Kind regards,
Tobias
Quoting Terry Reedy <tjre...@udel.edu>:
On 7/16/2020 9:51 PM, Tobias Kohn wrote:
Hi Everyone,
I feel there are still quite a few misconceptions around concerning
PEP 622 and the new pattern matching feature it proposes. Please
allow me therefore to take another attempt at explaining the ideas
behind PEP 622 with a different approach. Bear in mind that I
naturally cannot cover everything, though, and that some parts
presented here are still slightly simplified.
Thank you Tobias. I am a fan of looking at things from multiple
viewpoint. For 200 years, physicists argued about whether light is
waves or particles, before discovering that 'neither' and 'both'
were more correct.
1. Function Overloading
2. Visitor Pattern and Dispatch > 3. Shape and Structure
[snip, snip, snip]
In an assignment statement, the code to the left of '=' is a 'target
list' of 'target's, with some idiosyncratic rules. Even though it
might, misleadingly, be called a 'target expression', it is not an
expression to be evaluated. Similarly, the code between parentheses
in a def statement is a 'parameter list' of 'defparameter' and
special symbols, with other idiosyncratic rules. Both could be
called 'binding lists' or more generally, 'binding structures'.
To me, the important point of your point is that 'case' is somewhat
analogous to 'def', and that the stuff between 'case' and ':' is a
binding structure. We should call this structure a 'match
structure'. It is misleading and confusing to call it a 'match
expression'. A match structure consists of a 'match list' of 'match
items' or 'matcher's and an optional "'if' <condition>".
Matchers have a 3rd, new, and larger set of idiosyncratic rules.
The optional condition is an escape hatch for when expressing the
intended match constraint and corresponding match set is difficult
or worse using the match rules.
As with target and parameter items, untagged simple name matchers
are (and I now see, should be) binding targets. (The parameter list
tags are ':' for types and '=' for default values.) Unlike
assignment targets, dotted names and subscriptings are not binding
targets. Like parameter lists, match lists include literals. Match
lists also include syntactic structure not seen in the other binding
structures.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/NNZ67OMAV2CDV7GSX64SOLUAERJSF5HP/Code of Conduct:
http://python.org/psf/codeofconduct/
_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/6XZXGOHDBRN5ZXREZWB74DYHUGIEPLYI/
Code of Conduct: http://python.org/psf/codeofconduct/
