On Tue, May 24, 2016 at 7:03 PM Greg Ewing
Michael Selik wrote:
My main point is that switch/case/matching is semantically identical to if/elif, so why use something different?
But then you say
No, using the assign-if-can operator would be syntax error outside of an if/elif, the reverse of how an assign operator is a syntax error inside an if/elif.
So what you're proposing is *not* semantically equivalent to composing the existing if/elif with a new pattern matching assignment, which means re-using the existing keywords for it is misleading.
Perhaps I didn't explain my proposal correctly. I spent about 3 hours this evening writing out a more thorough proof of the semantic equivalence. As I did so, toying with different syntaxes, I realized that it might be better to break this problem apart and solve a few subproblems first. The first problem to solve is how to write a destructuring bind for more than just sequences. Once we're happy with that, it'll be easier to discuss pattern matching. # Iterable-destructuring bind (a.k.a unpacking) (a, b, *rest) = sequence # Subscriptable-destructuring bind {'x': p, 'y': q} = mapping {0: p, 42: q, **rest} = indexable # Attribute-destructuring bind (a few awkward ideas) (.x: p, .y: q) = obj (x=p, y=q) = obj Or would you call that "object-destructuring"? No clue what the best name is here. I think Clojure side-steps attributes and only provides destructuring sequences and mappings. If you want to do pattern matching on a more complex type, you must provide essentially a conversion from that type to a mapping.
The exception-catching expression is not meant to be available in
any other context. However, exception-catching is an essential feature to matching via destructuring. I believe it's unavoidable, though *which* exceptions are suppressed could be made more clear.
my assumption was that there was nothing special about the right hand side, so the implementation would have to just evaluate all of it and catch any AttribteErrors, KeyErrors, IndexErrors, etc. emanating from it, which is much looser and prone to catching too much.
But if the right hand side is special, all bets are off and you'll have to explain exactly what would be allowed and how to interpret it.
I agree that catching all exceptions during the assign-if-can (via if/elif or switch/case) might be too error-prone. Whether it's the LHS of ``as`` or the RHS of ``?=``, it would help to restrict the kind of exceptions handled/suppressed as a failed match. However, I fail to see why ``case ... as ...`` would be restrictive and ``if ... ?= ...`` would not. They could have the same semantics, catching either a specific set of exceptions or all/most exceptions.