On Thu, Jan 9, 2014 at 6:18 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 8 January 2014 17:32, Mark S. Miller <erights at google.com> wrote:
> > On Wed, Jan 8, 2014 at 2:33 AM, Andreas Rossberg <rossberg at google.com>
> > wrote:
> >> On 7 January 2014 20:44, Allen Wirfs-Brock <allen at wirfs-brock.com>
> wrote:
> >> > Unless we can identify real implementation issues, the semantics of
> >> >    do { }
> >> >
> >> > should simply be those of a blocks.
> >>
> >> I don't think this flies anyway. It has to be more like a function
> >> body, otherwise var and function declarations would hoist out of it,
> >> which would be insane IMO.
> >
> > strict function declarations don't hoist out of blocks, so the hoisting
> > issue is var only.
>
> Good point.
>
> > I would find it surprising if var declarations did not
> > hoist out of do expressions.
>
> Interesting. I have the exact opposite expectation. And I don't see
> what good it would do usability-wise.


Now that we have const and let, vars serve no usability purpose whatsoever.
However, given their existence in the language, the best we can do with
them usability-wise is to follow the principle of least surprise. Since we
have opposite surprise reactions, this doesn't tell us what to do, but at
least we should be able to agree on this criterion.



> >> What I'm arguing for, then, simply is to make it as much like a
> >> function body as possible. (That also matches the current IIFE
> >> practice best.)
> >>
> >> Also, I really would want to avoid examples like
> >>
> >>   return do { break; }
> >>
> >> and similar craze.
> >>
> >> Is there a convincing example where cross-expression jumps would
> >> actually be useful?
> >
> >
> > If all we want is sugar for IIFEs, I wouldn't bother. With arrow
> functions,
> > IIFEs are already a lot shorter. The extra brevity of do expressions is
> not
> > worth it.
>
> It's not only the brevity as such, but having a natural, targeted
> language feature. IIFEs are merely an encoding, and as such a
> distraction. Like A + -B is brief enough, but I'm sure you prefer
> saying A - B.


In a language with infix + and unary -, *and the absence of prior
expectations of an infix -*, the pressure to add an infix minus is small
for exactly this reason. A repeated pattern often comes to be perceived as
a phrase. In the absence of infix minus or prior expectations, A + -B would
rapidly become seen to do what it does.

I do have one usability concern with arrow IIFEs. I hate when I see them
written as ()=>{...whatever...}() because you don't know that it's an IIFE
until the end. Function expressions have the same issue. We should adapt
Crock's recommended paren style to arrow IIFEs, to whit
(()=>{...whatever...}()), even though this looses a bit more brevity.



>
> > What would make do expressions worthy of consideration is if they
> repaired
> > the TCP violations of strict arrow IIFEs, including var, arguments,
> break,
> > continue, return, and especially yield.
>
> Can you clarify what you mean by "repair"? I hope you don't suggest
> that "while (true) { (() => do { break })() }" should magically work.
>

No, I am not suggesting that code within the do block is TCP wrt the
context outside the function containing the do expression. This would be a
TCP violation wrt the context of the do expression. Rather, I suggest that
the following must work:

    while (true) { do { break; } }



>
> I may warm up to the extra complexity more easily if somebody could
> present at least some compelling use cases. :)
>
> /Andreas
>



-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140109/95689548/attachment.html>

On Thu, Jan 9, 2014 at 6:18 AM, Andreas Rossberg <rossberg at google.com>wrote:

> Interesting. I have the exact opposite expectation. And I don't see
> what good it would do usability-wise.


Now that we have `const` and `let`, `var`s serve no usability purpose whatsoever.
However, given their existence in the language, the best we can do with
them usability-wise is to follow the principle of least surprise. Since we
have opposite surprise reactions, this doesn't tell us what to do, but at
least we should be able to agree on this criterion.

> It's not only the brevity as such, but having a natural, targeted
> language feature. IIFEs are merely an encoding, and as such a
> distraction. Like A + -B is brief enough, but I'm sure you prefer
> saying A - B.


In a language with infix + and unary -, *and the absence of prior
expectations of an infix -*, the pressure to add an infix minus is small
for exactly this reason. A repeated pattern often comes to be perceived as
a phrase. In the absence of infix minus or prior expectations, A + -B would
rapidly become seen to do what it does.

I do have one usability concern with arrow IIFEs. I hate when I see them
written as `()=>{...whatever...}()` because you don't know that it's an IIFE until the end. Function expressions have the same issue. We should adapt Crock's recommended paren style to arrow IIFEs, to whit
`(()=>{...whatever...}())`, even though this looses a bit more brevity.



> Can you clarify what you mean by "repair"? I hope you don't suggest
> that `while (true) { (() => do { break })() }` should magically work.

No, I am not suggesting that code within the `do` block is TCP wrt the
context outside the function containing the `do` expression. This would be a
TCP violation wrt the context of the `do` expression. Rather, I suggest that
the following must work:

```js
while (true) { do { break; } }
```