const VS features detection

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Jan 7 11:44:52 PST 2014


On Jan 7, 2014, at 8:22 AM, Andreas Rossberg wrote:

> On 7 January 2014 17:19, Andreas Rossberg <rossberg at google.com> wrote:
>> Sorry, my wording may have been ambiguous. What I meant was
>> disallowing break/continue/return inside a 'do', not giving up 'do'.
>> ;)
> 
> And just to be extra-clear: by that I'm only referring to "free"
> occurrences of those, that would refer to the enclosing statement.
> Nested ones are fine, of course.
> 

Unless we can identify real implementation issues, the semantics of
   do { }

should simply be those of a blocks.  JS programmer shouldn't have to learn which subset of statement are invalid in a do expression block.  In particular, I see no reason why a JS programmer should be able to refactor any valid BlockStatement in to an equivalent ExpressionStatement simply by putting a 'do' in front of the leading '{'

The meaning of things like:
   function (x) {
      for (let i of x.state!==special? x : do {return bar(x)}) 
           foo(i)
   }

is clear and also easy enough to specify.  Unless there are some non-obvious implementation issues, I don't see why we would want to disallow such things.

The only place where the possible semantics isn't totally obvious is things like:
     for (x of z ? q : do {break}) ...
or
     for (x of do { if (z)  q; else continue}) ...

The semantics in the ES6 draft for an unlabeled break or continue completion in the head of a for statement threats both of these as terminating the for statement and continuing with the statement following the for.

Allen


> /Andreas
> 
> 
>> On 7 January 2014 17:10, Brendan Eich <brendan at mozilla.com> wrote:
>>> Andreas Rossberg wrote:
>>>> 
>>>> - YAGNI -- I have a hard time coming up with a use case that isn't
>>>> obfuscated code (even considering generated code).
>>> 
>>> 
>>> Always a good reason in the abstract, but concrete use cases have arisen,
>>> even in this thread. As you noted just last month (!),
>>> 
>>> 
>>> """
>>> 
>>> For ES7 I would like to revive the do-expression proposal (hopefully
>>> at the next meeting), so that one can at least approximate the above
>>> with
>>> 
>>>  const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false }
>>> };
>>> 
>>> Of course, semantically the function is equivalent, and a fine
>>> solution, if a bit verbose.
>>> 
>>> 
>>> """
>>> 
>>>> - They complicate the semantics and implementation -- for example, you
>>>> would have to roll back non-empty expression stacks (in a stack
>>>> machine implementation).
>>> 
>>> 
>>> This is minor in both actual effect (not many naive recursive expression
>>> parse-tree walkers) and implementation hardship (return completion types all
>>> over, respect abrupt ones in expression handlers).
>>> 
>>> 
>>>> - They destroy nice equivalences -- in particular, I'd like "do {...}"
>>>> to be equivalent to "(() =>  {...})()", e.g. to minimise refactoring
>>>> hazards.
>>> 
>>> 
>>> What changed your mind from 20-December?
>>> 
>>> Anyway, JS has statements and expressions, but functions create new
>>> activations with their own scopes. Those create hazards when refactoring
>>> between statements and expressions.
>>> 
>>> Wanting the equivalence you state here tries to deny the facts of JS and its
>>> full (ahem, perhaps disputed legitimacy) heritage.
>>> 
>>> 
>>>> - We can always allow them later, if the need should ever arise.
>>> 
>>> 
>>> ES7 is later.
>>> 
>>> /be
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140107/e35c7542/attachment.html>


More information about the es-discuss mailing list