Function length

[Russell Leggett]

On Tue, Jun 12, 2012 at 1:06 PM, Brendan Eich <brendan at mozilla.org> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120612/89057125/attachment.html>