<div dir="ltr"><div class="gmail_quote"><div><span style="line-height:1.5">On Tue, May 24, 2016 at 7:03 PM Greg Ewing <<a href="mailto:greg.ewing@canterbury.ac.nz">greg.ewing@canterbury.ac.nz</a>> wrote:</span><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Michael Selik wrote:<br>> My main point is<br>
> that switch/case/matching is semantically identical to if/elif, so why<br>
> use something different?<br>
<br>
But then you say<br>
<br>
 > No, using the assign-if-can operator would be syntax error outside of an<br>
 > if/elif, the reverse of how an assign operator is a syntax error inside<br>
 > an if/elif.<br>
<br>
So what you're proposing is *not* semantically equivalent<br>
to composing the existing if/elif with a new pattern matching<br>
assignment, which means re-using the existing keywords for<br>
it is misleading.<br></blockquote><div><br></div><div><div>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.</div></div><div><br></div><div>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.</div><div><br></div><div># Iterable-destructuring bind (a.k.a unpacking)</div><div>(a, b, *rest) = sequence</div><div><br></div><div># Subscriptable-destructuring bind</div><div>{'x': p, 'y': q} = mapping</div><div>{0: p, 42: q, **rest} = indexable<br></div><div><br></div><div># Attribute-destructuring bind (a few awkward ideas)</div>(.x: p, .y: q) = obj<div>(x=p, y=q) = obj</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> The exception-catching expression is not meant to be available in<br>
> any other context. However, exception-catching is an essential feature<br>
> to matching via destructuring. I believe it's unavoidable, though<br>
> *which* exceptions are suppressed could be made more clear.<br><br>
my assumption was that there was nothing special about<br>
the right hand side, so the implementation would have to<br>
just evaluate all of it and catch any AttribteErrors,<br>
KeyErrors, IndexErrors, etc. emanating from it, which is<br>
much looser and prone to catching too much.<br>
<br>
But if the right hand side is special, all bets are off<br>
and you'll have to explain exactly what would be allowed<br>
and how to interpret it.<br></blockquote><div><br></div><div>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.</div></div></div>