block lambda revival

Peter Michaux petermichaux at gmail.com
Sat May 21 10:05:13 PDT 2011


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


More information about the es-discuss mailing list