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.
/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
domenic at domenicdenicola.com (2014-01-14T17:39:37.661Z)
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.
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. /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