block lambda revival

Brendan Eich brendan at
Sat May 21 11:05:42 PDT 2011

On May 21, 2011, at 10:38 AM, Jorge wrote:

> On 21/05/2011, at 16:43, Brendan Eich wrote:
>> On May 20, 2011, at 9:55 PM, Peter Michaux wrote:
>>> On Fri, May 20, 2011 at 5:54 PM, Brendan Eich <brendan at> wrote:
>>>> An essential part of this proposal is a paren-free call syntax
>>> Why is that essential?
>> The argument, as I understand it from Smalltalk, Ruby, and E experts, is empirical, and in part a matter of intentional design: users write blocks as actual parameters to make control abstractions. Most such abstractions taking block arguments do not let those blocks escape through the heap or a return value -- the blocks are downward funargs. This aids in making new control abstractions more efficient than functions to implement, as well as more usable. Built-in control flow statements have (optionally) braced bodies that do not need parenthesization, so why should new ones created by users passing blocks?
>> When I wrote essential, I was not claiming that there's a logical proof of necessity. Rather I was declaring that this strawman includes paren-free block-argument-bearing call expressions as an essential design element. (...)
> <fwiw>
> I for one do like explicit call()s better, the way it's always been in JS. ( and it's just 2 chars ),

You are always free to over-parenthesize. Blocks can be passed as primary expressions too (I left that out of the grammar, sorry -- fixing).

> perhaps because I can't avoid to see it as a plus to share syntax with C.
> C is one of the -if not the- most important languages in history, and I can see good reasons for you wanting to borrow from its syntax back then, in 1995 (but even now, too, because it's *still* one of the most important and popular languages)

Sorry, it depends on audience. A lot of programmers these days (more's the pity in my view) do not learn C. They learn Java. Others come up at GitHub University (;-) and learn dynamic languages with significant newlines and even significant whitespace. It's not the C/Unix world I knew from my youth.

> But I can't say so much of borrowing from coffeescript's syntax ? Perhaps in 30 years, we'll see :-)

The arrow syntax is in many languages. I did take => from CoffeeScript because binding |this| is quite common and it seems to me it ought to have shorthand that does not prejudge it as uncommon or with some puritanical sin-tax.

Yes, one wants languages such as C to telegraph micro-economics: shorter forms should be more efficient, ceteris paribus. No hidden unexpected costs. JS is not such a language and has never been, even before getters and setters.

> Why the (sudden) urge to copy so many bits ( paren-free, -> // =>, etc ) of coffee's syntax ? (does JS have an identity crisis now ?)

Please lose the attitude. Look around you, the world is not C and it's not 1995. I look at many languages, like Steve Yegge and others (Guy Steele has written about this eloquently), I'm a polyglot and language lover when it comes to programming languages.

Language chauvinists tend to draw lines in the sand and make war. That's silly, self-limiting.

True, some languages are not much used due to their flaws, and we can learn from those. But popular languages are used in spite of their technical flaws, too.

It pays to look at what people actually use, and learn why they like it. In that light, I've approached CoffeeScript as a source of potential good ideas. We in TC39 are certainly not standardizing CoffeeScript, and Jeremy Ashkenas doesn't want anything like that. Rather, we're trying to modernize JS enough so that some of the pressure for transpiled languages is reduced, and in any event so that the transpilations are simpler and more efficient.

Languages are not people, they do not have self-aware identities or identity crises. Languages do have skin (surface syntax) or to use a trope I prefer, clothing. Clothing involves aesthetics as well as utility, usability, ergonomics. C and JS patterned on it are hardly the last word or the latest mode.

Since the early days of Lisp, syntax design and even support for multiple syntaxes for the same semantics have formed an evolving art. That evolution continues, whether you like it or not, and developers can vote with their fingers and virtual feet. You see this most clearly on

> WRT the syntactic noise that these () ; {} etc introduce in the source: I don't like the way children write their SMSs either, everything are shorthands and there's no punctuation marks: sure it's faster to write, but not easier to read.

Shorter forms in programming languages can be faster to read too, though. Reading 'function' all over the place, e.g. in the Monadic Eval example Claus cited, is a drag. In no way does it win on pure reading, ignoring creation and maintenance aspects of writing.

> A bit less (syntactic) noise would be good. But a bit less isn't "let's make a new JS that not even a JS programmer can recognize".

People learn new forms. ES3 added function expressions and they were recognizable, but perhaps more confusing for looking like function declarations than if they had shorter syntax. Consider the de-facto semi-standard still being mooted: eval("function (...) {...}") done to compile a specialized function. That source is not a valid Program, it's an anonymous function expression.

> I'm a JS programmer that isn't ashamed of its C heritage, and I don't think needs that breaking change.

Now you are making a false statement, on two counts:

1. JS is not entirely governed by its C heritage. Where pray tell does 'function' occur in C? C functions are much more concise.

2. No one, least of all me, has proposed *breaking* anything, as in breaking compatibility. The proposed extensions are not in general breaking changes (useless labels becoming early errors in Harmonoy aside, and that is a separable proposal).

> I'd put the stress in the other important things more than in trying to make it look more "current-fashion".

"Fashion" as better, more usable syntax is not only aesthetics and fluff, or a racket to sell more new clothes before the old ones wear out.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list