Hi Mark,
Thank you for your interest and the questions.
1. This really comes down to how you look at it, or how you define
pattern matching. The issue here is that the concept of pattern
matching has grown into a large and somewhat diverse flock of
interpretations and implementations (as a side note: interestingly
enough, some of the only universally agreed-upon standards are to use
`_` as a wildcard and not to mark names that capture/bind
values---which are quite exactly the points most fiercely debatted
here).
Anyway, the paper presents the pattern matching structure we are
proposing as one of three major variants of pattern matching:
(a) Matching arguments to parameters in a function call,
(b) Matching elements to elements in iterable unpacking,
(c) Matching tree-like data to general patterns in a conditional
pattern matching structure.
The last one is the subject of the PEP and the paper. Nonetheless, in
the first two cases (a) and (b), we find that indeed the computer will
validate that the data matched the pattern and raise an exception if
this fails. This is where this way of looking at it comes from.
2. Yes, that is indeed a deliberate simplification. The idea is to
abstract away from the details of how exactly Python implements
abstract syntax trees (which I honestly believe are irrelevant for the
sake of the entire narrative). Moreover, using strings here allows us
to exemplify the literal patterns, rather only showcasing only the
constructor/class pattern.
Essentially, this is a question of making the most out of the little
space available.
Since you have addressed this email to me directly, I would like to
take this opportunity and briefly stress that this paper really grew
out of a team effort. While I might have been the one pushing for an
academic publication, the DLS'20 paper represents the input and ideas
of all the authors, as well as the long discussions we had. Of
course, I am happy to answer any questions about the paper, but it
would be wrong to see me as the one person behind it.
Cheers,
Tobias
Quoting Mark Shannon <m...@hotpy.org>:
Hi Tobias,
A couple of questions about the DLS 2020 paper.
1. Why do you use the term "validate" rather than "test" for the
process of selecting a match?
It seems to me, that this is a test, not a validation, as no
exception is raised if a case doesn't match.
2. Is the error in the ast matching example, an intentional
"simplification" or just an oversight?
The example:
```
def simplify(node):
match node:
case BinOp(Num(left), '+', Num(right)):
return Num(left + right)
case BinOp(left, '+' | '-', Num(0)):
return simplify(left)
case UnaryOp('-', UnaryOp('-', item)):
return simplify(item)
case _:
return node
```
is wrong.
The correct version is
```
def simplify(node):
match node:
case BinOp(Num(left), Add(), Num(right)):
return Num(left + right)
case BinOp(left, Add() | Sub(), Num(0)):
return simplify(left)
case UnaryOp(USub(), UnaryOp(USub(), item)):
return simplify(item)
case _:
return node
```
Cheers,
Mark.
_______________________________________________
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/ETZGYRCF4DR6RJXTHGXIRZXINXJ76J2D/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/CUNO57W7KSIM2WRROC5R43ZT7HUQZCZ6/
Code of Conduct: http://python.org/psf/codeofconduct/
