Russell Leggett wrote:
It does bring up something else, though, that I've avoided mentioning
so far, which is pattern matching. I haven't mentioned it because
there is clearly a strawman
<http://wiki.ecmascript.org/doku.php?id=strawman:pattern_matching> for
it, and that never made it to harmony, but in light of this thread I
wanted to reiterate how useful it would be. It would not really help
function.length, but would address the real underlying problem that
the arity dispatcher is trying to tackle. In a language without
overloading, the ability to do pattern matching would be an excellent
solution to a very common problem. We already have destructuring, it
seems like such a small jump to pattern matching.
You are preacher, dherman and I are choir. Maybe patterns will make ES7.
We shall try again.
Hard to tell from looking at the strawman why that never made it. If
its a matter or feature bloat, I would rate that higher than some
other things like default args or array comprehensions.
See March 2011 TC39 meeting notes, second day.
Quotes below. Note some fine specimens of TC39's future-proofing
fetishization on parade. I will say no more, as I think Dave agrees
patterns were not fully baked.
The way to get refutable matching into ES7 is to work now to address all
the valid worries, and say why the other worries are false.
/be
[From https://mail.mozilla.org/pipermail/es-discuss/2011-March/013403.html]
Refutable matching and switch extensions:
Multiple objections to syntax chosen for pattern-matching switch:
colon vs. no colon after default clause, need for blocks, etc.
Refutable matching doesn't retrofit into imperative switch syntax
well.
Waldemar: Refutable matching is half-baked at this point, with too
many syntactic and semantic problems. Not clear it's worth its added
complexity.
The refutable matching wiki has the following consequences on
irrefutable matching:
Pattern [x,y]:
Matched to [3,4], produces x=3, y=4.
Matched to [3,4,5], produces x=3, y=4.
Matched to [3], produces x=undefined, y=undefined. (wiki spec bug.)
Pattern [..., x, y]:
Matched to [3,4], produces x=3, y=4.
Matched to [3], looks up negative array indices. (wiki spec bug.)
Pattern [x,y] behaves like [x,y,...] for refutable matching. (wiki spec bug.)
Can't match on zero-length arrays. (wiki spec bug?)
Lucas: Feature value should overcome complexity costs.
Waldemar: if guards introduce unknown syntactic and semantic complexity
Waldemar: where can you use refutable matching outside of switch/match
statements and perhaps catch guards? switch/match statements are too
heavyweight and differ too much from irrefutable matching assignment;
catching doesn't really need destructuring but benefits from
conditions. The typical usage (as in Perl) is to use them in if
statements: if (pattern =~ expr) {we have matched!}
catch({z,w} if z< w): OK, but then you can't get to the entire
exception object from the catch clause.
catch(z if z instanceof T): Useful
Waldemar: Refutable matching should integrate trademarking to be compelling.
Concern about backing ourselves into a corner by implementing
irrefutable pattern matching in catch guards that will later preclude
refutable matching. Brendan's example: catch({x, y}) would succeed
on {x:3} now but fail later if we change to refutable pattern
matching.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
