block lambda revival

David Herman dherman at mozilla.com
Sat May 21 11:20:13 PDT 2011


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 <waldron.rick at gmail.com> 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
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list