Stream: wasm

Topic: components: are module and component types index spaces


view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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)

view this post on Zulip 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.

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 20:25):

is following that precedent the right choice?

view this post on Zulip Luke Wagner (Feb 09 2022 at 20:31):

I think so

view this post on Zulip 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

view this post on Zulip 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?

view this post on Zulip 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.

view this post on Zulip 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)

view this post on Zulip 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

view this post on Zulip Peter Huene (Feb 09 2022 at 20:53):

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

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 20:54):

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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip 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

view this post on Zulip Peter Huene (Feb 09 2022 at 20:56):

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

Repository for design and specification of the Component Model - component-model/Binary.md at ast-and-binary · WebAssembly/component-model

view this post on Zulip Peter Huene (Feb 09 2022 at 20:57):

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

view this post on Zulip Peter Huene (Feb 09 2022 at 20:57):

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

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 20:57):

okay, but valuetype ::= intertype

view this post on Zulip Peter Huene (Feb 09 2022 at 20:57):

but those aren't intertypes :)

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 20:58):

so are value types in the type index space?

view this post on Zulip Peter Huene (Feb 09 2022 at 20:58):

yes

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 20:58):

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

view this post on Zulip Peter Huene (Feb 09 2022 at 20:59):

no

view this post on Zulip Peter Huene (Feb 09 2022 at 20:59):

only the indexes in start functions

view this post on Zulip Peter Huene (Feb 09 2022 at 20:59):

refer to value types

view this post on Zulip Peter Huene (Feb 09 2022 at 21:00):

which are why intertype and valuetypes are different semantic things

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 21:00):

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

view this post on Zulip Peter Huene (Feb 09 2022 at 21:02):

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

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 21:03):

yes that would be very helpful

view this post on Zulip 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

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 21:04):

so much simpler

view this post on Zulip 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

view this post on Zulip 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)

view this post on Zulip fitzgen (he/him) (Feb 09 2022 at 21:05):

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

view this post on Zulip 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

view this post on Zulip 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?"

view this post on Zulip 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: Dec 23 2024 at 13:07 UTC