Function length

Brendan Eich brendan at mozilla.org
Tue Jun 12 10:06:45 PDT 2012


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.




More information about the es-discuss mailing list