Boolean shortcuts

Brendan Eich brendan at mozilla.com
Wed Jan 4 14:56:03 PST 2012


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 https://mail.mozilla.org/pipermail/es-discuss/2011-June/015568.html) on unifying blocks and object literals, inspired by others on this list, but it didn't pan out. It's increasingly future-hostile as we try to extend object literals.

Trying to invert precedence so "{}" as a program source makes an empty object instead of an empty block, IOW favoring expressions over statements, is a breaking change. Not only for eval, but for other variants such as javascript: URLs.

So, I've put unifying blocks and object literals on the back burner. A more nuanced approach that doesn't break compatibility so much would be welcome, but I don't see it.

/be


> 
> Herby
> 
> -----Pôvodná správa----- From: François REMY
> Sent: Wednesday, January 04, 2012 10:50 PM
> To: mikesamuel at gmail.com ; es-discuss
> Subject: Re: Boolean shortcuts
> 
> 
> “You already have to.” –> If something is bad, don't change it?
> 
> (1) Block expressions are not useful because you can't use them as expressions (=retreive their value) if you don't use “string eval”.
> (2) Object syntax is restricted because lookahead comes at a cost for parsers.
> 
> This is a mess. Beginners hate it. Parsers don't like it. And yet it's still there...
> 
> Personnaly, I would like to do something like that (and I remind an earlier proposal from the mailing list) :
> 
>   // try to create an "x" variable
>   let x = try { doSomething() } catch (ex) {};
> 
> or
> 
>   // log the value of 1+2+3+...+10
>   console.log (eval { let i=10, j=0; while(i) { j+=i—; } });
> 
> Now, I have to do something like that :
> 
>   // not as readable
>   let x; try { x=doSomething() } catch (ex) {}
> 
> or
> 
>   // bad but close in term of input
>   console.log(eval("let i=10, j=0; while(i) { j+=i--; }"));
> 
>   // as optimized, but not as readable
>   { let i=10; let j=0; while(i) { j+=i--; }; console.log(j); };
> 
> The introduction of the “eval” keyword before a block has tons of other advantages :
> 
>   {}.toString(); // will now compile and return “[object Object]” from anywhere in the code
> 
> That means I can do something like :
> 
>   let props = eval {
>       let obj   = func();
>       let prop1 = getProp1(obj);
>       let prop2 = getProp2(obj, prop1);
>       {
>           prop1: prop1,
>           prop2: prop2
>       }
>   }
> 
> Another proposed syntax, namely
> 
>   this.function() {} <—> (function() {}).bind(this)
> 
> will now be acceptable since
> 
>   function() {
>       return this.function(); //ASI
>       {
>           doSomething();
>       }
>    }
> 
> is not allowed in ES6, there’s no syntax conflict. So, we can introduce the [noLineBreak] token after “function” safely.
> 
> BTW, I also think we should drop labels for ES6. This will help to simplify syntax, too. With ES6, we should build a new syntax that’s more logical to use.
> 
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss



More information about the es-discuss mailing list