On Wed, Jun 13, 2012 at 12:42 PM, Andreas Rossberg <[email protected]>wrote:
> 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). > 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 method. > > > >> 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 >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
