Previously, you argued against the importance syntactic convenience, but it seems what you really were opposed to was a new function form that wasn't a true lambda. But now that there is one back on the table, you're OK with counting conciseness as a win.
I don't mean to single you out on this-- it's a general phenomenon on es-discuss that really frustrates me. Design discussions are dysfunctional when they're treated as a zero-sum game between opponents. Design requires being honest about trade-offs. When people feel threatened that their concerns aren't being taken into account, they get defensive and start discounting others' concerns, and then the whole thing becomes a negative feedback loop. For my part, I will do my best to at least listen to people's concerns and register them as part of the equation, even if not every design can fulfill every constraint. I haven't always succeeded at that, but I'll do my best. I hope everyone will try to do the same. Dave On May 21, 2011, at 10:05 AM, Peter Michaux wrote: > On Sat, May 21, 2011 at 7:56 AM, Rick Waldron <[email protected]> wrote: >> Brendan, >> Thanks for the clarification on that. >> I've been following the shorter function syntax discussions pretty closely, >> as well as reading the strawman proposals, so please forgive me if this has >> been addressed or refuted. >> Given your example: b = a.forEach (x) { x * x } And the issues you noted >> there, would the same issues apply here: >> b = a.forEach( (x) { x * x } ) >> ^ ^ > > I don't see a prefix being a problem to reduce ambiguity. It would > actually be beneficial for readability. > > b = a.forEach( lambda(x) { x * x } ) > > It seems this strawman is proposing true lambdas so the name is apt. > It sure is easy to Google "JavaScript lambda" or search code for > "lambda". > > functionreturn is 14 characters. lambda is 6 characters. That is a > 8/14 character savings which is pretty good for those worried about > character count. I don't know why we have to be so extreme and get the > savings up to 12/14. In the case that the lambda has a few possible > return points the savings on repeated "return" would be repeated > savings. > > This strawman is much more interesting because it is not just sugar. > It introduces something JavaScript does not have now which is a real > lambda and that could take JavaScript in positive directions in the > future. Many syntax possibilities and macros need to desugar to a real > lambda that obeys Tennent Correspondence Principle, correct? Opening > that door for the future would be beneficial. > > I'm understanding the intention of the strawman correctly? > > Peter > _______________________________________________ > es-discuss mailing list > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
