Boolean shortcuts

Herby Vojčík herby at
Mon Jan 9 03:20:01 PST 2012


I have looked at the links and as I understand they are trying to accomplish 
something slightly different, by adopting code as kind of data, though it is 
interesting, too (and your are true do-expressions do it elegantly, except 
for the "explicit zero-arg lambda" thing (I think || is not tragedy)".

I was trying to do something different - not bring code verbatim into data, 
but powerful code constructs into data - I had posted it in thread "RFC: 
Empowered data - unification of code block and object literal(and class)". 
It more a unification of code block and data block to be more similar in 
appearance as well as expressiveness (while retaining their 
imperatice/declarative nature).

As for the "empty-block/object issue" I realized it is a non-issue (or, 
little issue), I was freaked out. :-) This is old known things that {}.f() 
does not work until one parenthesizes {} and it is the same (anooying, but 
nothing breakingly new) category of quirk.


P.S.: Still got no comment on above-mentioned thread. :-(

P.P.S.: And back to boolean shortcuts: would there be a possibility (and 
demand for them)? I posted my '{ value: "foo", configurable, writable, 
!enumerable }' and 'var !done, !!soFarSoGood' and someone mentioned there is 
this kind of proposal in CoffeeScript land which goes more like '{ value: 
"foo", +configurable, +writable, -enumerable }' and 'var -done, 

-----Pôvodná správa----- 
From: Brendan Eich
Sent: Thursday, January 05, 2012 12:03 AM
To: es-discuss
Subject: Re: Boolean shortcuts

On Jan 4, 2012, at 2:56 PM, Brendan Eich wrote:

> On Jan 4, 2012, at 1:57 PM, Herby Vojčík wrote:
>> Hi,
>> as I already posted in the parallel thread, there is that strawman called 
>> "do expression" by dherman that does just that.
>> I feel like crying when I see how powerful data constructs could be if 
>> not hampered by "possible to parse as code block" ambiguity.
> Yes, I have felt like crying too -- I did some work (see 

I should have also linked:

Of course,

is much simpler.

Neither addresses the empty-block/object issue by trying to evaluate {} as 
an object literal where today it's a block statement.


es-discuss mailing list
es-discuss at 

More information about the es-discuss mailing list