On 11/23/2020 3:44 PM, David Mertz wrote:
I have a little bit of skepticism about the pattern matching syntax, for similar reasons to those Larry expresses, and that Steve Dower mentioned on Discourse.

Basically, I agree matching/destructuring is a powerful idea.  But I also wonder how much genuinely better it is than a library that does not require a language change.  For example, I could create a library to allow this:

m = Matcher(arbitrary_expression)
if m.case("StringNode(s)"):
    process_string(m.val)
elif m.case("[a, 5, 6, b]"):
    process_two_free_vars(*m.values)
elif m.case("PairNone(a, b)"):
    a, b = m.values
    process_pair(a, b)
elif m.case("DictNode"):
    foo = {key, process_node(child_node) for key, child_node in m.values.items()}

I don't disagree that the pattern mini-language looks nice as syntax.  But there's nothing about that mini-language that couldn't be put in a library (with the caveat that patterns would need to be quoted in some way).

I just commented on Steve's post over on Discourse. The problem with this is that the called function (m.case, here) needs to have access to the caller's namespace in order to resolve the expressions, such as StringNode and PairNone. This is one of the reasons f-strings weren't implemented as a function, and is also the source of many headaches with string type annotations.

My conclusion is that if you want something that operates on DSLs (especially ones that can't be evaluated as expressions), the compiler is going to need to know about it somehow so it can help you with it. I wish there were a general-purpose mechanism for this. Maybe it's PEP 638, although I haven't really investigated it much, and pattern matching might be a bad fit for it.

Eric