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 exactly why lambdas are needed in JavaScript and which use cases 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, switch, etc.

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).

/be

_______________________________________________
Es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss

Reply via email to