On Tue, Jun 12, 2012 at 1:06 PM, Brendan Eich <[email protected]> wrote:
> 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<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. > This thread gave me an interesting idea on how to possibly attack pattern matching in ES6 with no new syntax, and still leave room for more sugar later. It actually comes from thinking about the original issue with function.length and using it for arity-based dispatch. What if we just gave a better method than length? What if we had something like function.matches(args)? Where it would return true if all arguments were bound, and no parameters resulted in an undefined binding. function add(a,b){ return a + b; } add.matches(1,2); // => true add.matches(1); // => false add.matches(1,2,3); => false This still suffers from the same problem as function.length, and when dealing with simple arity and no destructuring/rest params, would act exactly the same. However, Irakli's dispatcher utility does lay the groundwork for something more interesting. function makePoint(x,y){ return {x:x,y:y}; } function drawLine({x:x1,y:y1},{x:x2,y:y2}){...} let p1 = makePoint(1,2), p2 = makePoint(3,4); drawLine.matches(p1,p2); // => true drawLine.matches(1,2); // => false drawLine.matches({x:1}, {y:2}) // => false //only has to be a structural subset drawLine.matches({x:1,y:2,z:3}, {x:1, y:2}) // => true With that simple boolean function, Irakli's dispatcher utility could be rewritten to loop through the list and check for a match instead of by arity. It would work correctly for rest parameters, but even more interesting, would work with all of the destructuring patterns. let drawLine = dispatcher( (x1,y1,x2,y2) => ..., ({x:x1,y:y1},{x:x2,y:y2}) => ... ); Or a more functional replacement for switch let result = match(value, ({x,y,z}) => "3d" ({x,y}) => "2d" (...anything) => "not a point" ); Its not as nice as full pattern matching with literals and wildcards, but it could be pretty clean. If guards were added later, that would be an obvious fit. If it became a popular pattern, we could pave the cowpath with some sugar, and add the things that are missing now. One of the benefits of getting started this way is that it could be shimmed to just use length.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
