On Sat, May 21, 2011 at 11:20 AM, David Herman <[email protected]> wrote: > 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 must not have been clear enough with what I wrote with regard to conciseness. I wrote the following... > 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. The "for those worried about character count" part was intentional and did not include me with regard to reducing the length of function literals. I don't see how that is motivation Peter > 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
