Function length

[Andreas Rossberg]

On 13 June 2012 15:25, Russell Leggett <russell.leggett at gmail.com> wrote:
> On Wed, Jun 13, 2012 at 5:29 AM, Andreas Rossberg <rossberg at google.com>
>> 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).


>> 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.


>> 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.

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.

/Andreas