Rename catch_br

[rossberg]

The name catch_br is misleading, since it is not a branch in the regular sense. In particular, catch_br $l jumps to a different place than br $l. Possible suggestion: catch_delegate.

[aheejin]

I don't mind either way. Do people have objections or other suggestions for the name? (Do we need a vote for this? I guess not, right?)

[ioannad]

The name catch_br is misleading, since it is not a branch in the regular sense. In particular, catch_br $l jumps to a different place than br $l. Possible suggestion: catch_delegate.

I also don't mind changing the name, but I must say I didn't realise that catch_br $l branches to a different place than br $l. I though we just have to validate that $l is indeed a try block. Is this not the case?

[aheejin]

Yes, I think we should verify it too. $l should be attached to a try, and catch_br (or catch_delegate) should transfer, or delegate, the exception searching path to the corresponding catch/unwind of try specified by the label.

Whether $l is attached to try of catch is just a matter of text syntax, because in binary the argument will be an immediate integer.

EDIT: I think this comment is misleading and incorrect; I posted a new explanation here: #133 (comment)

[rossberg]

@ioannad, a regular br jumps past the whole try statement, while catch_br goes to its catch/unwind part. The former also carries along potential arguments (depending on the type of the label), whereas the latter is agnostic of the label type.

[RossTate]

Taking the "skip over" interpretation of catch_br in #130, catch_br should not specify what try to delegate to; it should specify how many trys to skip over. This would also provide an answer to how to specify the caller as whom to delegate to.

[rossberg]

It does, but it counts other control constructs as well. That makes finding the target try in the control stack O(1) in an implementation instead of O(N), and doesn't require a separate try stack.

[RossTate]

That makes sense. Note then that with the "skip over" interpretation, there is no need for the target to be a try. That is, catch_br is essentially saying "for any exceptions thrown from in here, pretend their continuation does not include the n+1 immediately enclosing control constructs".

[tlively]

FWIW, if we do determine that this construct is sufficiently different from br, I like delegate as the verb to use. It would be nice to use plain delegate instead of catch_delegate because 1) "try-delegate" rolls off the tongue better than "try-catch_delegate" and 2) it's more inclusive of unwind as well as catch. If delegate seems too general a name, though, I would be fine with catch_delegate as well.

[rossberg]

@tlively, sounds good to me. Given that it's part of a larger try construct, delegate would be unambiguous enough. I mean, even end is. :)

@RossTate's suggestion about generalising this is interesting. It essentially turns this into a rethrow_in sort of construct. In fact, if we generalised rethrow that way we wouldn't even need a separate try-delegate statement, but could just replace that with a (try ... catch_all (rethrow_in $l)).

[RossTate]

Interesting idea, @rossberg, although this catch_br is supposed to apply to unwinding as well, not just exceptions.

[aheejin]

Sorry, I think I said something incorrect in #133 (comment).

What I intended was the immediate arg for catch_br (or whatever its name will be) only counts trys and not other constructs such as blocks or loops. This may require a separate try stack but I thought it was clearer. I think I implied the opposite in #133 (comment) by saying we need a validation to see if $l is really a try; I was incorrect. $l will be an immediate in binary, and if we only count trys, we don't need that validation. (Maybe we need validation for immediate values that exceeds the (try stack depth + 1), but that's a separate thing)

Do people here mean we should also count other blocks/loops as well? I'm little confused, but if there's a good enough reason, I think we can consider that.

[aheejin]

@rossberg

@RossTate's suggestion about generalising this is interesting. It essentially turns this into a rethrow_in sort of construct. In fact, if we generalised rethrow that way we wouldn't even need a separate try-delegate statement, but could just replace that with a (try ... catch_all (rethrow_in $l)).

When we have two-phase, rethrow within a catch block will run after both two phase unwinding is finished, and will not be accessible to first phase search. This is the reason I proposed catch_br rather than adding a label to existing rethrow. (I once suggested adding a label to rethrow to fix unwind mismatch (#74), but that was when we weren't considering two-phase.)

@tlively I think try-delegate sounds good too.

[takikawa]

Do people here mean we should also count other blocks/loops as well? I'm little confused, but if there's a good enough reason, I think we can consider that.

I had also thought that (counting other blocks/loops) was the intended behavior until this thread. I think if the catch_br name is kept it would make sense to make the index numbering consistent with br and count the other control constructs. If the name is changed, maybe this point of consistency isn't as important but it does seem easier to implement without the additional stack.