Function length

Russell Leggett russell.leggett at
Wed Jun 13 14:15:49 PDT 2012

On Wed, Jun 13, 2012 at 12:42 PM, Andreas Rossberg <rossberg at>wrote:

> On 13 June 2012 15:25, Russell Leggett <russell.leggett at> wrote:
> > On Wed, Jun 13, 2012 at 5:29 AM, Andreas Rossberg <rossberg at>
> >> 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.
> >
> > I'll respond a little out of order by saying that you believe patterns
> > independently implemented would be simple and efficient. If that is the
> case
> > (and I would think it was), then I don't really see how your argument
> holds
> > water. Let's just say we actually had patterns. I'll make an imaginary
> > syntax for them.
> >
> >     let pattern = #({x,y});
> >     pattern.matches({x:1,y:2});
> Well, that's not how other languages do pattern matching, or what the
> strawman proposes. Rather, you usually have a generalisation of what's
> the switch statement in JS, see the strawman. It makes matching,
> binding and dispatching into a single operation that can be compiled
> into efficient decision trees fairly easily (although JS's getters
> make matters less pleasant).

Right, I understand that. Yeah, I suppose my syntax was a little odd
towards helping my case. However, there is also this bit from Waldemar:

"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!}"

If I could have my dream version of matching, it would probably be similar
to scala/haskell/erlang. We could maybe use "case" instead of "switch" at
the top. Not sure if that's confusing, but haskell/erlang use it and its
already reserved. Something like:

    case p of {
        [x,y] => ...
        {x,y} => ...
        *     => throw ...

Which I would greatly prefer over the modified switch statement version. It
would be an expression, and have an intuitive tie in to arrow functions. As
you can see from this syntax, though, it's very similar to what can be
achieved using a match function taking arrow function arguments. But even
this form could be reduced down to a single pattern returning true, and a
default returning false and that would be the equivalent of a matches

> >> 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 guess to me this is just functional programming - its effectively a
> > callback for each pattern. The one which matches gets called. I don't see
> > why its so different than using forEach instead of a for loop. One is
> more
> > expressive and functional style, the other is more efficient.
> The different with forEach is that there is only one closure, and it's
> usually executed. In the case of a match, you'll have to create N
> closures while knowing that at most 1 will actually be called.

Depending on the way you used it, the set of closures could easily be
reused for multiple calls, the same way that Irakli's dispatcher helper
works. My point was more that developers have to weigh the tradeoffs for
expressivity vs efficiency now, and this would be no different.

> >> 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.
> >
> > I would much prefer to have it as a full, proper language construct, and
> I
> > would not have suggested function.matches if I thought it would be future
> > unfriendly to adding them. On the contrary, my hope is that this would
> be a
> > low footprint feature, but would provide the tool missing to allow for
> the
> > community to play with patterns. One of the great things about
> JavaScript is
> > its flexibility, and the community has really used that to create the
> > cowpaths we later pave. As a way of figuring out the best way to add full
> > patterns to the language, wouldn't it be helpful to give people this
> small
> > feature and see what the result is?
> That's the thing: the feature you suggest is only superficially
> "small". Once you look closer it actually is much *bigger* and more
> intrusive than what's in the strawman. You avoid new syntax, but
> that's a small win compared to the (significantly!) larger complexity
> in terms of semantic interference and efficient implementation.

I'll just have to defer to you on that. If its really large, I guess I'll
have to accept that, it just doesn't seem as large as you say it is. For
any function with vanilla es5 parameters, its simply an arity check. Is the
length the same as the number of arguments? That number is already known
and available as function.length, and should add no extra overhead to
functions with no special parameter syntax. Beyond that, the work to do the
match does not seem like it should be much beyond what already has to
happen for destructuring. For destructuring, you still have to handle the
mismatch case, and bind to undefined. Performing a refutable match would
just fail in those cases. I must be oversimplifying.

> It's good to play with ideas, but if your primary motivation really is
> getting something accepted into the standard, then I'm not sure that
> this one would be an easier sell.

I'm not trying to get something into the standard for the sake of getting
it in if that's what you mean. It genuinely seemed useful and still does. I
can think of a dozen variations on this which would be useful. And one
other thing it does well that pattern matching using a switch does not, is
actually look like pattern based dispatch in the cases where you want to
match on multiple args, and not just a single value. It also allows for a
sort of reified pattern/rule than can be played with by libraries/apis. In
the same way that the right low level tools have allowed for people to
write libraries for classes/traits/promises etc. this could be a building
block to allow for new types of expressive apis.

- Russ

> /Andreas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list