malbarbo ( Marco A L Barbosa )

+# 3rd proposal formal spec overview++This is an overview of the 3rd proposal's formal spec additions, to aid in discussions concerning the proposed semantics.++## Abstract Syntax++### Types++Exception Types++```+exntype ::= [t*] -> []+```++### Instructions++```+instr ::= ... | throw x | rethrow l+        | try bt instr* (catch x instr*)+ end+        | try bt instr* (catch x instr*)* catch_all instr* end+        | try bt instr* delegate l+        | try bt instr* unwind instr* end+```++### Modules++Exceptions (definitions)++```+exn ::= export* exception exntype  | export* exception exntype import+```++Modules+++```+mod ::= module ... exn*+```++## Validation (Typing)++To verify that a `try...delegate l` instruction refers to a label introduced by a try block (I'll call this a try-label), introduce a type attribute to labels in the validation context, which type attribute is set to `try` when the label is a try-label. The original notation `label [t*]` will then be a shortcut for `label {result [t*], type ε}`.++Moreover, to verify that the `rethrow l` instruction refers to a label introduced by a catch block (call this a catch-label), we allow this type attribute of labels in the validation context to be set to `catch` when the label is a catch label. This addition is reflected in the execution rules, by the administrative instruction `caught` which introduces a label around the instructions of the catching try-block's catch instructions.

I just pushed the promised commits. The first one's commit message contains the question "Should the administrative instruction caught be removed from the right hand side of rethrow's execution step?", because I ran out of time and I won't be able to think about it until the end of next week.

ioannad

comment created time in 12 hours

PR closed WebAssembly/threads

Mark explainer as outdated

+4 -0

1 commit in surma/threads/tree/patch-1 WebAssembly/threads/tree/master

8 comments

1 changed file

surma

pr closed time in 16 hours

pull request commentWebAssembly/threads

Mark explainer as outdated

Absolutely. Cheers.

surma

comment created time in 16 hours

pull request commentWebAssembly/threads

Mark explainer as outdated

@surma are you happy for this to be closed now that wabt has been updated? Please let us know if you're still dealing with inconsistencies.

surma

comment created time in 17 hours

Pull request review commentWebAssembly/exception-handling

formal spec overview for the 3rd exception handling proposal

+# 3rd proposal formal spec overview++This is an overview of the 3rd proposal's formal spec additions, to aid in discussions concerning the proposed semantics.++## Abstract Syntax++### Types++Exception Types++```+exntype ::= [t*] -> []+```++### Instructions++```+instr ::= ... | throw x | rethrow l+        | try bt instr* (catch x instr*)+ end+        | try bt instr* (catch x instr*)* catch_all instr* end+        | try bt instr* delegate l+        | try bt instr* unwind instr* end+```++### Modules++Exceptions (definitions)++```+exn ::= export* exception exntype  | export* exception exntype import+```++Modules+++```+mod ::= module ... exn*+```++## Validation (Typing)++To verify that a `try...delegate l` instruction refers to a label introduced by a try block (I'll call this a try-label), introduce a type attribute to labels in the validation context, which type attribute is set to `try` when the label is a try-label. The original notation `label [t*]` will then be a shortcut for `label {result [t*], type ε}`.++Moreover, to verify that the `rethrow l` instruction refers to a label introduced by a catch block (call this a catch-label), we allow this type attribute of labels in the validation context to be set to `catch` when the label is a catch label. This addition is reflected in the execution rules, by the administrative instruction `caught` which introduces a label around the instructions of the catching try-block's catch instructions.

@aheejin I see now what you mean, yes, you are right.

In the second example, the label from the catch block would interfere with delegate, when it shouldn't. Also rethrow should not interfere with other labels, it should just count the stack of nested catch blocks it is in - to rethrow an exception, an exception must be caught, so we can only rethrow n the exception caught by the nth surrounding catch block.

I think to solve this, the catch-labels should be removed, and a separate concept of a caught-stack should be added to the runtime, described by a parallel to blocks:

C^0 ::= val^m [_] instr
C^{n+1} ::= caught{exnaddr val^k} C^n end

Also a new stack caught to validation contexts, which gets an element "caught" prepended whenever we catch an exception by a catch block.

About the 3rd example, did you omit a catch in the outer try block on purpose, meaning that trys without catches could be allowed, as @tlively suggested in #131 ? In that case, in your 3rd example, if we replace ... by throw $exn then the example would reduce to throw $exn. I think it would be a nice simplification to the syntax to allow catchless try blocks. They are equivalent to try ... catch_all rethrow 0 end AFAICT, so no new behaviour would be introduced with this simplification.

If we additionally allow delegate to target any label, as @RossTate suggested, then we can have the same effect also without a try block, as he noted, and we wouldn't have to make any changes to labels. I admit I am not so fond of adding this auxiliary information to labels, I just thought I had to.

To clarify I'll commit the changes I'm suggesting later today, in three separate patches:

add caught-stack to the runtime and to validation contexts and remove catch-labels (which actually should have been called "caught" labels but anyway)
allow trys without catches
remove auxiliary type of labels and allow delegate to reference any label

WDYT?

ioannad

comment created time in 18 hours

pull request commentWebAssembly/threads