Function length

[Andreas Rossberg]

On 12 June 2012 23:57, Russell Leggett <russell.leggett at gmail.com> wrote:
> 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

OK, I'll bite. I see lots of problems and unnecessary complexity here.

If I understand this correctly, then it will require every function
closure to include meta information for performing the associated
pattern match. Or, when you actually want this to be optimised, the
ability to generate (probably lazily) and attach pattern matching code
to _every_ function closure. That seems pretty intrusive.

Also, the programmer would have to create a closure for every match
arm you ever want to use (unless the compiler is "sufficiently clever"
to recognise rather non-trivial patterns, which I doubt). That is
likely to be pretty costly. I'm also not sure how you envision
actually binding variables during a match. Are you suggesting that one
does something like:

  if (f.matches(x, y)) f(x, y)

Even if this is abstracted into some 'match' function, a match would
redundantly decompose x, y for f twice.

And just to be clear, this feature also reveals implementation details
of a function that it shouldn't. For example, it allows you to observe
cases where a function ignores some of its documented arguments, or
some parts of its arguments. So it has all the bad properties of the
'isBound' function we discussed earlier.

I'd say (despite being part of the pattern matching choir) that this
is not the proper way to introduce a feature that, as a proper
language construct, would be relatively simple, efficient, and
independent of anything else.

/Andreas