petermichaux at gmail.com
Sat Jun 18 13:02:10 PDT 2011
On Sat, Jun 18, 2011 at 11:53 AM, Brendan Eich <brendan at mozilla.com> wrote:
> On Jun 18, 2011, at 10:33 AM, Peter Michaux wrote:
> Yet CoffeeScript does not need lambdas with TCP control effects today. It
> translates in a straightforward (mostly) "transpiling" way. Even its
> expression-language mapping of statements as expressions does not require
Maybe CoffeeScript doesn't need it today. Another source language
> > language to their likes and needs. So it seems that developers have
> > can do that right now. They are, however, limited by the features that
> > doors for the source languages.
> Sure. The problem is drawing the line, as we've discussed in this list since
> 2006 (when Nicholas Cannasse brought up call/cc).
Drawing the line in the right place is important of course. I was
trying to contribute to the case that drawing the line with lambdas in
would be beneficial to some and perhaps a growing group in the future.
> > The most interesting part of the block lambda proposal is adding
> That's not yet evident. Yes, some source languages (and some compiler
> writers) would want lambdas. Not all, and the compiler writers seem to be
> doing fine working around lack of lambdas:
I don't think that list proves too much. Many of those languages are
fact, this may be partly why CoffeeScript is the first language that
> > Often a heavy
> > function is not a good idea in the compiled code and the lack of
> > Tennent's Correspondence Principle for functions means the compilers
> > need to do big tricks to get the compiled code to do what is desired.
> > a source language could add efficient let blocks quite easily.
> How efficient is wide open to question. VMs implementing let can more
> readily optimize without having to optimize lambdas in full (TCP effects
Fair enough. I don't know which VM implementations would benefit or suffer.
> It seems to me you are using the expressive power of lambda to
> argue for efficiency, which is makes a category mistake.
I didn't intend that.
> What is the current feeling about the block lambda proposal in TC39?
> What can be done to help move the block lambda proposal towards
> I noted the reaction here and in talks I've given, citing the straw poll I
> took about arrow functions, lambdas, there-can-be-only-one. 8/6/unanimous
> (some abstained). IOW, TC39 wants at most one
> lambda-or-just-shorter-function syntax (lambda carries semantics). The
> committee was mixed on arrow functions with Waldemar concerned about
> grammatical issues I've tried to address in the strawman. Others were quite
> in favor of arrows.
> Block lambdas were more divisive, in part because of the syntax, but in
> larger part (IMHO) because of the novel TCP semantics. Some on the committee
> decried "excessive bits of cleverness". Others said "won't this confuse
> n00bs?" (Meta-discussion #27
> from http://www.slideshare.net/BrendanEich/txjs-talk). More than a few were
> quite in favor, though (Allen, Dave Herman, Mark Miller).
> So, a mixed reaction and no consensus for ES.next.
So what can be done to help move the block lambda proposal towards Harmony?
More information about the es-discuss