Semantics and abstract syntax of lambdas

Brendan Eich brendan at mozilla.com
Thu Dec 18 11:20:57 PST 2008


On Dec 18, 2008, at 10:36 AM, Peter Michaux wrote:

> On Thu, Dec 18, 2008 at 8:43 AM, Brendan Eich <brendan at mozilla.com>  
> wrote:
>> On Dec 18, 2008, at 6:45 AM, Lex Spoon wrote:
>>
>>> x => x+1
>>> x => {{ var y = x+1; y*2 }}
>>
>> There's no need to double braces in the => syntax if we require an  
>> object
>> initialiser to be parenthesized:
>>
>> x => ({p: 1, q: true})
>
> Why cause such extra confusion for programmers?

What "extra" confusion?

You already have to parenthesize an object initialiser in statement  
context, e.g. as entire program source passed to eval in ES3+, or as  
the body of an expression closure or let expression in JS1.7.

Why penalize *every other* lambda body with doubled braces for the  
rare hard case of a lambda whose body is an object initialiser  
expression? Hard cases make bad law.


> Unfortunately I've lost most of my interest in this discussion as some

Yeah, we know. Don't assume I'm on board with => either. But this was  
a bikeshedding exercise, as Lex allowed. And he made a better case for  
=> as purtiest shed-color than anyone else has so far :-P. (Not to say  
purtier than other colors, just the best case for => so far.)


> folks seem to be desperately in need of some sort of new syntax. I
> just don't get it. The lambda(){} syntax would work just fine without
> any new feature conflicts. Even if all known conflicts have kludge
> workarounds to enable some terse sugary syntax, isn't anyone worried
> about the conflicts that will appear later?

I explicitly raised the issue Waldemar already raised, of conflicts or  
future-proofing when extending the grammar informally.

But you can't sell lambda with fear of alternatives. The big, non-bike- 
shedding issue remains: is TCP-uber-alles, or even just the completion  
value leakage hazard, a mismatch for most JS programmers? Rogue return  
from lambda unwinding a function unexpectedly, dynamic escape- 
continuation errors, expression languages... Sure, Schemers and  
similar expert folks love 'em. Are they worth the footgun-risks?

/be


More information about the Es-discuss mailing list