No code block without introductory keyword (was: Re: Booleanshortcuts)

Herby Vojčík herby at
Wed Jan 4 13:39:24 PST 2012


Brandon Eich recently mentioned do expression, so I looked them up
( It seems
they can have good use here (though it is by accident). It would verily be
possible to adopt "no { ambiguity" rule by mandating "all {....} uses must
have formal introductory context, including 'no context' which implies {...} 
a data-production use of {...}", in which case do expression would be ideal
to include a free code block anywhere it can be needed. No need to invent
new mechanism / keyword.


-----Pôvodná správa----- 
From: Herby Vojčík
Sent: Wednesday, January 04, 2012 2:51 PM
To: François REMY ; es-discuss at
Subject: No code block without introductory keyword (was: Re:


what you proposed seems like a pretty good idea (at least imho).
All other uses of {...} as code block have a introductory keyword / control
structure (if, else, while, do, function), and even the newcomer {...} uses
like module and class are preceded by one. If (maybe in "strict ES6+" only)
there was the general rule of "no code block without formal introduction",
it could make parsing much more quirk-free (and it would be clearly define
that {...} without introduction is _always_ object literal (or, more
broadly, data-producing {...} (declarative curlie)) in contrast to
imperative curlie that contains some form of action to perform).


-----Pôvodná správa----- 
From: François REMY
Sent: Wednesday, January 04, 2012 2:27 PM
To: Herby Vojčík ; es-discuss at
Subject: Re: Boolean shortcuts

I agree that code block is a complex feature that is (almost) never used and
that has many quirks.

If ES6 could remove it, I would not be upset at all. If it's here to stay,
we should at least have an introductory keyword like "eval { ... }" and
allow "var x = eval { ... }".

BTW, I think the reason of your inconsistency is a bug : eval("{}") should
return undefined, as in IE9. It seems that node.js has a special case for
{}, probably to avoid a common mistake. Or there's a bug in the parser, I
don't know.

es-discuss mailing list
es-discuss at

More information about the es-discuss mailing list