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 []).