David Herman (2013-05-13T23:15:24.000Z)
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> It closes down this whole edge-case focused discussion and that's valuable in itself.  Also, since it turns try {yield expr} finally{} into a syntax error  we could revisit the decision in a future edition if somebody actually comes up with compelling use cases.

I'm very uncomfortable with this restriction. Ad hoc restrictions break compositionality. They come back to bite you because you broke generality for want of use cases, when we all know we can't predict all the use cases of a general-purpose programming mechanism. This gets our responsibility backwards: ad hoc restrictions that break generality should be extremely strongly motivated, rather than requiring use cases for the semantics they disallow.

Meanwhile this point:

> It's all about "finally" which up to now has been a strong guarantee.

is wrong. (I've explained this in past meetings, I think at an Apple meeting a year or two ago.) The guarantee of finally does *not* provide a *strong* (total) guarantee, it provides a guarantee of the "partial correctness" flavor:

    """
    If control reaches the end of the execution of the try block, either by normal completion or abrupt completion, then execute the finally block before proceeding.
    """

A good intuition (and an equivalence that we should strive to preserve) is that `yield` is acting like a function call to the main continuation, which can choose to return back to the generator or not. This is just the same as if you write:

    function infiniteLoop() { while (true); }

    try {
        infiniteLoop();
    } finally {
        console.log("and now we are done");
    }

We don't guarantee anything about execution of finally blocks if control never reaches the end of their try blocks.

Dave
github at esdiscuss.org (2013-07-12T02:27:21.156Z)
On May 13, 2013, at 11:07 AM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:

> It closes down this whole edge-case focused discussion and that's valuable in itself.  Also, since it turns `try {yield expr} finally{}` into a syntax error  we could revisit the decision in a future edition if somebody actually comes up with compelling use cases.

I'm very uncomfortable with this restriction. Ad hoc restrictions break compositionality. They come back to bite you because you broke generality for want of use cases, when we all know we can't predict all the use cases of a general-purpose programming mechanism. This gets our responsibility backwards: ad hoc restrictions that break generality should be extremely strongly motivated, rather than requiring use cases for the semantics they disallow.

Meanwhile this point:

> It's all about `finally` which up to now has been a strong guarantee.

is wrong. (I've explained this in past meetings, I think at an Apple meeting a year or two ago.) The guarantee of finally does *not* provide a *strong* (total) guarantee, it provides a guarantee of the "partial correctness" flavor:

    """
    If control reaches the end of the execution of the try block, either by normal completion or abrupt completion, then execute the finally block before proceeding.
    """

A good intuition (and an equivalence that we should strive to preserve) is that `yield` is acting like a function call to the main continuation, which can choose to return back to the generator or not. This is just the same as if you write:

```js
function infiniteLoop() { while (true); }

try {
    infiniteLoop();
} finally {
    console.log("and now we are done");
}
```

We don't guarantee anything about execution of `finally` blocks if control never reaches the end of their `try` blocks.