So one thing that lambda really helps with, and where TCP is a serious practical issue and not just philosophical, is macros.
Macros need the ability to create new kinds of control flow by taking expressions and reordering and delaying them. You can use 'function' for this but you don't want the expressions to change their meaning in a handful of clunky ways (this, arguments, return, etc.). Otherwise you have to say things like "this macro takes an expression and a statement -- but they can't refer to this or arguments, can't use yield or return or break or...". (Incidentally, turning the TCP violators into errors isn't much of a fix; it fails fast, which is better, but it still means that subterms that use |this| or |arguments| or whatever just can't be used with the macro.) I have some thoughts about how to approach macros for JS, and I know there's at least some interest both on the committee and in the wider community for macros. In the sense that macros are lightweight language extensions, transpilers like CoffeeScript could also benefit from blocks if they wanted to add features that delay evaluation. For example, a `lazy' construct for thunking an expression that can be forced on demand, such as in an event callback. That's just one example, but lambda is pretty much the fundamental building block for building features by shallow translation (aka macro expansion, aka desugaring, aka transpilers). This doesn't change the fact that being able to execute a return statement after its function has already returned is a new kind of error that wasn't there before. Personally, I blame return as the feature at fault... but sadly that horse left the barn somewhere in the 60's or 70's. ;) Dave On Jun 18, 2011, at 4:14 PM, Brendan Eich wrote: > On Jun 18, 2011, at 1:50 PM, Brendan Eich wrote: > >> On Jun 18, 2011, at 1:02 PM, Peter Michaux wrote: >>> So what can be done to help move the block lambda proposal towards Harmony? >> >> To me the biggest obstacle is the meta-point about "OMG too different" >> regarding return, break, and continue having TCP conformance. At least one >> TC39er also wanted |this| to be other than lexical (i.e., TCP-conformant). I >> don't know how to overcome this meta-discussion point. Arguing endlessly >> about it does not get anywhere. > > A couple of more thoughts: > > * I said at #txjs that instead of endless meta-discussions, we should > "address concrete use-cases, fill language gaps". That requires showing how > concrete use-cases unserved by function today are served by lambda, or else > showing a language gap that needs filling for a more subtle reason. > > * Implementing block-lambdas as an extension in a real browser and then > winning developers support, where the developers convey their wish in large > enough numbers to other browser vendors, would do it. Clearly this can take a > while (getters and setters, array extras). > > /be > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
