Stream: wasm

Topic: components: are module and component types index spaces

fitzgen (he/him) (Feb 09 2022 at 20:13):

Are component, function, and module types in the same index space as intertypes?

Specifically, is it valid (syntactictically? semantically?) for the "indexed" version of intertype (intertype ::= i:<typeidx> => type-index-space[i]) to reference a component/function/module type?

cc @Luke Wagner @Luke Wagner @Peter Huene @Dan Gohman @Alex Crichton

Alex Crichton (Feb 09 2022 at 20:14):

AFAIK it's all one type index space, yeah, and validation ensures that it's well-formed

fitzgen (he/him) (Feb 09 2022 at 20:14):

or do only the valuetypes/intertypes within a type section correspond to entries in the type index space

fitzgen (he/him) (Feb 09 2022 at 20:15):

Alex Crichton said:

AFAIK it's all one type index space, yeah, and validation ensures that it's well-formed

if that's the case, why have one single, hetergeneous types space instead of multiple homogeneous types spaces (one for component types, one for function types, one for value types, etc)

Luke Wagner (Feb 09 2022 at 20:22):

In general, wasm index spaces are heterogeneous in that they contain different types of things and it's validation, not index space, which ensures everything is well-formed. If anything, it's questionably a design mistake that wasm didn't have just have one big index space for everything. In the particular case of the type index space, post-MVP wasm proposals are already adding other type constructors (beyond func) to the type section, so we're just following that precedent.

fitzgen (he/him) (Feb 09 2022 at 20:25):

is following that precedent the right choice?

Luke Wagner (Feb 09 2022 at 20:31):

I think so

Peter Huene (Feb 09 2022 at 20:42):

i also think so; to be pedantic, though, intertype aren't in the type index space, only compoundintertype are and the i:<typeidx> variant of intertype must validate to a compoundintertype

fitzgen (he/him) (Feb 09 2022 at 20:47):

Peter Huene said:

intertype aren't in the type index space

the types section is a vec(type) and we can have type ::= deftype ::= valuetype ::= intertype are we supposed to dynamically validate that this production never occurs?

Peter Huene (Feb 09 2022 at 20:50):

value types aren't the same thing as intertype, just that value types are defined in terms of intertype. nowhere in the grammar can you refer to an intertype by type index, but you can refer to value types by index.

Peter Huene (Feb 09 2022 at 20:50):

(confusingly overloaded name of "value type" aside since we have that in many places to mean i32, i64, etc from core wasm)

fitzgen (he/him) (Feb 09 2022 at 20:53):

why does the grammar allow type sections to contain non-compound valuetypes if that isn't allowed? seems easy to statically eliminate in the grammar, rather than dynamically in validation

Peter Huene (Feb 09 2022 at 20:53):

it doesn't. the top-level type rule only has the compoundintertype variant

fitzgen (he/him) (Feb 09 2022 at 20:54):

I see type ::= deftype ::= valuetype as a valid parse, when looking at the grammar

fitzgen (he/him) (Feb 09 2022 at 20:54):

type              ::= dt:<deftype>                               => dt
                    | cit:<compoundintertype>                    => cit
deftype           ::= mt:<moduletype>                            => mt
                    | ct:<componenttype>                         => ct
                    | it:<instancetype>                          => it
                    | ft:<functype>                              => ft
                    | vt:<valuetype>                             => vt

fitzgen (he/him) (Feb 09 2022 at 20:56):

wait now when I refresh, to see if the grammar has changed, the page is gone

Peter Huene (Feb 09 2022 at 20:56):

right, you can define value types in the type index space, but i'll reclarify you can't define intertypes

Peter Huene (Feb 09 2022 at 20:56):

https://github.com/WebAssembly/component-model/blob/ast-and-binary/design/mvp/Binary.md

Peter Huene (Feb 09 2022 at 20:57):

| Are component, function, and module types in the same index space as intertypes?

Peter Huene (Feb 09 2022 at 20:57):

from the original question, just pointing out intertype aren't in the index space

fitzgen (he/him) (Feb 09 2022 at 20:57):

okay, but valuetype ::= intertype

Peter Huene (Feb 09 2022 at 20:57):

but those aren't intertypes :)

fitzgen (he/him) (Feb 09 2022 at 20:58):

so are value types in the type index space?

Peter Huene (Feb 09 2022 at 20:58):

yes

fitzgen (he/him) (Feb 09 2022 at 20:58):

are indexed <intertype>s allowed to refer to valuetypes?

Peter Huene (Feb 09 2022 at 20:59):

no

Peter Huene (Feb 09 2022 at 20:59):

only the indexes in start functions

Peter Huene (Feb 09 2022 at 20:59):

refer to value types

Peter Huene (Feb 09 2022 at 21:00):

which are why intertype and valuetypes are different semantic things

fitzgen (he/him) (Feb 09 2022 at 21:00):

this would be so much less confusing if these were different index spaces

Peter Huene (Feb 09 2022 at 21:02):

also probably better expressed by => type-index-space[i] iff: compoundintertype or some such

fitzgen (he/him) (Feb 09 2022 at 21:03):

yes that would be very helpful

fitzgen (he/him) (Feb 09 2022 at 21:04):

I have to create and maintain different index spaces that point into the heterogeneous types index space for wasm-smith to generate valid components, I feel like we might as well just actually have different index spaces

fitzgen (he/him) (Feb 09 2022 at 21:04):

so much simpler

fitzgen (he/him) (Feb 09 2022 at 21:05):

the only argument I've heard for not doing it is "following precedent" which would make sense if there were no advantages to not following precedent, but that isn't the case here

Alex Crichton (Feb 09 2022 at 21:05):

FWIW this isn't something new that wasm-smith deals with, the existing module-linking generator should handle this (not that it's pretty, just that it should)

fitzgen (he/him) (Feb 09 2022 at 21:05):

am I missing some other reason why a single heterogeneous type space is good?

fitzgen (he/him) (Feb 09 2022 at 21:06):

Alex Crichton said:

FWIW this isn't something new that wasm-smith deals with, the existing module-linking generator should handle this (not that it's pretty, just that it should)

yeah and I feel like that isn't great either

Peter Huene (Feb 09 2022 at 21:42):

i mean there is something to adhering to the core spec in this regard (the core spec currently being type homogeneous notwithstanding) and that each entry in a type section increments the singular type index space (i.e. there's no individual sections for the different types), but then again there exists precedence in both formats where a section (e.g. imports) doesn't have any index space at all and each entry increments a set of heterogeneous index spaces. i guess that's a long way of saying "i guess i'm on the fence after all?"

Peter Huene (Feb 09 2022 at 21:43):

i do agree that perhaps we need a better reason than that's how core does it when core never had more than one type at the start

Last updated: Nov 22 2024 at 16:03 UTC