Event vs. exception?

[aheejin]

In the core spec, we are currently using the term 'event' to represent a tag that can be used to match an exception object in catch instructions. An event contains a signature, in which the result type is always void. Two different event can contain the same signature.

The term 'event' was suggested years ago out of concern that there will be more kinds of events that will be added to the event section. See https://github.com/WebAssembly/exception-handling/blob/master/proposals/exception-handling/old/Exceptions-v2-Level-1%2BN.md#level-3 for examples of thought then.

Recently JS API addition proposal was suggested in #154 and it uses the term exception to represent an exception, which I think fine, but the consistency in the terminology in the core spec and the JS API comes to mind. Also #150 (comment) has several links to previous comments on possible event vs. exception terminology.

I am OK with either, but I think we should be consistent on the terminology in the core spec and the JS API spec.

Do we still plan to add other kinds of events to the event section? Are other stack switching or coroutine primitives planning to use the section?

cc @rossberg @ioannad @takikawa @RossTate @tlively

[tlively]

Relatedly, would we consider renaming a section in future spec releases? I do anticipate that we will have new kinds of events in the future, so either we will want to keep the name "event section" or we will want to rename the "exception section" to "event section" in the future. Personally, I think renaming a section would be unnecessarily disruptive, so I would prefer keeping the name "event section." But if we keep the name "event section," it would be weird not to use "event" terminology to describe the contents of that section as well. So I think using "event" throughout the spec is the more forward-looking option. I would be fine with the JS API using "Exception," though, since that is the only kind of event it will be dealing with for now.

[aheejin]

@tlively If we are going to use different terminology for the core spec (event) and the JS API (exception), is the JS API not supposed to catch other kinds of events, even if they are represented with JS exceptions?

[tlively]

I would use Event as well for parts of the JS API that are expected to interact with future event types as well.

[fgmccabe]

The question of events is one of the design points in the Stack Switching efforts.
Currently, I would not say that 'event' in SS land will be the same as 'exception'. In fact, I would suggest there will be material differences. (Not the least of which will be an explicit note that events in SS will not include collecting stack traces.)

[tlively]

@fgmccabe I think the key question here is whether stack switching will extend the event section with new kinds of events. My impression is that all of the designs discussed so far have assumed that there will indeed be new kinds of events added to the event section. Is that your impression as well?

[fgmccabe]

This is a 'design point'. I.e., don't know at the moment.
However, if I have my druthers, I would want 'events' to be completely disconnected from both EH and SS. I do not look forward to having new kinds of events.

[RossTate]

I would call it something like the "tag" or "identifier" section. It's telling the engine to generate some unique tag and associate it with some type. The EH proposal then is using the tags to distinguish exceptions. But you could imagine the GC proposal adding something like tagref that uses the same tags as open variant types. (And you could imagine catch_as_tagref and throw_tagref instructions that convert between tagged references and exceptions, akin to what exnref did.) In these cases, the type associated with the tag is essentially a label type, but if stack switching were to use events then its tags would be associated with block types. And similarly Call Tags use tags associated with function types.

[rossberg]

"Event" is a bit overloaded and might cause confusion with completely unrelated notions of the same name, esp on the Web. Calling them "tags" sounds reasonable to me and perhaps makes clearer the distinction between a tag per se and a tagged value.

[takikawa]

I don't have a strong preference on this, and I'd be fine with the proposal to go with "tags". Concretely, I guess this would mean these changes:

• tag section instead of event section
• text format declarations could look like (tag $t (param i32))
• WebAssembly.Tag instead of WebAssembly.Exception. The constructor takes a TagType (currently defined to be { parameters: [ValType] } but could be extended with a result type or non-function types if useful for other tags in the future)

In this case we could also rename WebAssembly.RuntimeException to WebAssembly.Exception.

If WebAssembly.Tag could be used for other proposals (unlike the old WebAssembly.Exception), should the constructor take an attribute argument?

[aheejin]

I am OK with the name tag and tag section. By the way, does this mean that not all tags are supposed to be thrown and caught like exceptions, is my understanding correct?

@takikawa If we rename our JS API to Tag, would it be extensile to set the result type to be always empty?

[RossTate]

@takikawa To check if I am understanding you correctly: if the result of a wasm throw $tag gets caught by JS, that JS value will be a WebAssembly.Exception value that has a WebAssembly.Tag?

Supposing that understanding is correct, I would change WebAssembly.Tag to WebAssembly.LabelTag and have its constructor take a LabelType (still defined as you suggest). I think it's likely the tag section will have different kinds of tags, so I'd like to leave (ergonomic) room for that in the JS API. (Suspension events and call tags, for example, would likely be function tags that have function types.)

[aheejin]

@RossTate What is a label type? I am not aware of that concept in wasm but you keep using the term, so I'm wondering what I'm missing.

[RossTate]

The type of labels, e.g. what you check against when you type-check br $label. This is what I'm used to from typed assembly languages, but I see that apparently the spec's term for this is result type. So, to be consistent with the spec's terminology, maybe WebAssembly.ResultTag and ResultType would be better names.

[aheejin]

@RossTate That "result type" does not represent signatures of params to results in the form of (params) -> (results); it only represents the latter. In the MVP spec term, this was called function type; now given that it is used for more than functions (it is used in blocks for multivalue and also for EH), we can't use that name though.

[RossTate]

For br $label, the type of $label is the lait of value types that should be on the stack before br $label; that's a result type. For throw $tag, the type of $tag is the list of value types that should be on the stack before throw $tag; that's also a result type. I believe the confusion comes from the fact that WebAssembly uses block/function types in a number of places that should be label/result types, and from the fact that exceptions were expected to be extended to suspension events that can also return values (but even in this latter case, exception events return unreachable rather than []).

[aheejin]

The entries in the event section (or the tag section) contain references to signatures, not result types, which only consist of a list of types. So naming it ResultTag will be confusing, given that they are not result types in the first place. Also we don't have the concept of 'label type' so I'm not sure if that is a good name either.

If we think there is a possibility to add other kinds of events in the section, I think it's best to keep the name 'event section' or rename it to 'tag section'. If we think that section as a section for general reference for tags and we are not sure future references of tags can be all represented as JS exceptions, I think it's good to use Tag or Event to represent the tag and Exception to represent to the runtime exception that we can actually catch in JS.

[takikawa]

From @RossTate:

@takikawa To check if I am understanding you correctly: if the result of a wasm throw $tag gets caught by JS, that JS value will be a WebAssembly.Exception value that has a WebAssembly.Tag?

Yes, that matches what I was thinking.

Supposing that understanding is correct, I would change WebAssembly.Tag to WebAssembly.LabelTag and have its constructor take a LabelType (still defined as you suggest). I think it's likely the tag section will have different kinds of tags, so I'd like to leave (ergonomic) room for that in the JS API. (Suspension events and call tags, for example, would likely be function tags that have function types.)

Is the idea with your proposal that LabelTag would be used in order to distinguish tags that only take type parameters from ones that would, in the future, take full function types?

I was thinking we could potentially accommodate both with the same API. WebAssembly.Tag would presumably need to store the tag attribute (I was assuming we would keep this from the current event section), so it seems like this could be used to differentiate what types are accepted by the constructor.

For example, there could be WebAssembly.Tag({ parameters: ["i32"] }, "exception") and WebAssembly.Tag({ parameters: ["i32"], results: ["i32"]}, "call").

This is why I asked this question earlier:

If WebAssembly.Tag could be used for other proposals (unlike the old WebAssembly.Exception), should the constructor take an attribute argument?

Perhaps WebAssembly.Tag(TagType) with no attribute would default to the "exception" attribute for now, and in the future it would accept a second argument. Or maybe it should accept this second argument from the beginning? (it could also make sense to be the first argument if it's mandatory from the beginning)

If tags no longer carry an attribute field this wouldn't work of course, so that's a design question that needs to be resolved I think.

From @aheejin:

@takikawa If we rename our JS API to Tag, would it be extensile to set the result type to be always empty?

I think it could be extensible if in the future we allow the tag attribute to be set somehow, to distinguish the kind of tag.

[rossberg]

The point of naming it event (and renaming to tag) was to account for their potential use for other things than exception. The stack switching proposal e.g. uses them, and makes use of their ability to have function type. No good reason to abolish that ability. In any case, this issue is about naming, not changing semantics.

@takikawa:

Concretely, I guess this would mean these changes:

• tag section instead of event section
• text format declarations could look like (tag $t (param i32))
• WebAssembly.Tag instead of WebAssembly.Exception. The constructor takes a TagType (currently defined to be { parameters: [ValType] } but could be extended with a result type or non-function types if useful for other tags in the future)

In this case we could also rename WebAssembly.RuntimeException to WebAssembly.Exception.

All sounds right to me.

If WebAssembly.Tag could be used for other proposals (unlike the old WebAssembly.Exception), should the constructor take an attribute argument?

The binary format already reserves space for an attribute. In other places (text format, JS API), we can defer introducing it as an explicit component until needed, defaulting to the current meaning when omitted.

[aheejin]

If there is no other objections then, can we proceed with #159 (comment)?

[aheejin]

Reflected #159 (comment) in

• Spec explainer: Replace 'event' with 'tag' in explainer #161
• LLVM: https://reviews.llvm.org/D104423
• Binaryen: [EH] Replace event with tag binaryen#3937
• Wabt: [EH] Replace event with tag wabt#1678