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: [email protected] ; 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
