On 13 June 2012 15:25, Russell Leggett <[email protected]> wrote: > On Wed, Jun 13, 2012 at 5:29 AM, Andreas Rossberg <[email protected]> >> 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 _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
