Basic Lambdas and Explicit Tail Calls Repackaged
brendan at mozilla.com
Sun Dec 7 23:35:36 PST 2008
On Dec 7, 2008, at 9:55 PM, Michael Day wrote:
>> I agree with you: lambdas in http://wiki.ecmascript.org/doku.php?id=strawman:lambdas
>> look useless too. They don't have a clearly articulated vision nor
>> compelling use cases (at least not in the document).
> Right, can anyone clarify this? Is there a summary anywhere stating
> they are intended to satisfy?
We started with lambdas as better functions. They evolved due to a
combination of TCP idolatry (sorry, I call it as I see it :-P) and
some preference for Scheme-ish modeling of statements as if they were
part of an expression language (based on completion value precedent
used by eval).
We should back up and reconsider the goals. It seems to me that these
two main goals are in conflict:
1. Better functions, better meaning no |this| parameter and no
arguments object, possibly no var. For this item alone, TCP for var,
return, etc. seems undesirable. We could ban var, and make return
apply to the immediately enclosing lambda, which would thus not be
anything comparable to a Smalltalk block.
2. The ability to desugar existing and future syntax into kernel
semantics primarily using lambda coding and lexical bindings. As the
for loop desugarings Mark and David-Sarah worked out demonstrate, this
item wants var TCP at least, probably the full monty: |this|, return,
break, continue all apply to the lexically enclosing function, loop,
About return, break, and continue, I think Michael Day is onto
something in arguing that TCP loses when it comes to block-bodied
lambdas (if we have such, and we think we should, because the JS
expression language is too weak as Jon Zeppieri colorfully asserts).
What motivates aggressive TCP application is the second goal.
Is it possible to reconcile these goals? I don't think so. If not,
then 1 trumps 2 for a language catering to humans rather than, or
primarily over against, code generator programs or a relatively few
specifications that want to desugar, no matter the loss of clarity or
usability to most hand-coding users of the language. 2 trumps 1 if
it's all about Schemers and GWT or Volta or OpenLaszlo or Skynet :-P.
I say 1 trumps 2 for the reason given in the last paragraph: human
programmers first, meaning the fat bell curve (sorry, Schemers).
More information about the Es-discuss