modules types binary format · wasm

I think we'll probably want a separate index space for each kind of type, right?

Alex Crichton (May 18 2020 at 16:09):

like right now we only have the "type index space", but that's more realistically the "function type index space"

Alex Crichton (May 18 2020 at 16:09):

and module types are adding 2 more index spaces, the module types and instance types index space

Alex Crichton (May 18 2020 at 16:09):

Luke Wagner (May 18 2020 at 16:14):

Yup, index space per type. In MVP wasm we have have 5 index spaces (type, function, table, memory, global), and Module Linking would add 2 more (module and instance)

Alex Crichton (May 18 2020 at 16:15):

Luke Wagner (May 18 2020 at 16:15):

the "type" index space will grow to contain not just function typedefs, but also module typedefs, instance typedefs, and later GC typedefs

Alex Crichton (May 18 2020 at 16:15):

Alex Crichton (May 18 2020 at 16:16):

if I define one function, one module, and one instance type, all three indices are zero?

Alex Crichton (May 18 2020 at 16:16):

and I thought the existing "type" index space was going to be basically renamed to "function type" index space

Luke Wagner (May 18 2020 at 16:17):

in that situation you have 4 index spaces at play: a type index space with 3 types (0,1,2), and then single-element module index space (which defines the module, but also refers to the module's type in the type index space), and similarly a single-element instance and function index space

Alex Crichton (May 18 2020 at 16:17):

Luke Wagner (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:18):

Luke Wagner (May 18 2020 at 16:18):

Luke Wagner (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:19):

Luke Wagner (May 18 2020 at 16:19):

so you have this one index space of "type definitions" where all the types can refer to each other

Alex Crichton (May 18 2020 at 16:19):

oh you're thinking like "here's the N types of this module", and you verify all sub-indices are less than N ?

Luke Wagner (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:19):

I was imagining we'd still have just one type section, but it'd add to each respective index space depending on what's defined

Alex Crichton (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:20):

but because types refer to each other we can't validate until everything is parsed

Alex Crichton (May 18 2020 at 16:20):

Luke Wagner (May 18 2020 at 16:20):

Alex Crichton (May 18 2020 at 16:21):

hm wait then I still don't understand why we wouldn't have a separate index space for each class of types

Alex Crichton (May 18 2020 at 16:21):

if we assume you parse the whole type section, then you validate the whole thing

Luke Wagner (May 18 2020 at 16:23):

incidentally, i'm polishing up a change to the "Binary Format Considerations" section of the Module Linking PR which explains that we actually need to loosen up the section rules a bit so that you can split up and interleave the Type, Import, Module, Function and Alias Sections. The reason being that there is no longer a simple ordering of sections that prevents forward references. So rather, you can just have "some types" then "some modules" then .... and the index spaces grow monotonically, and validation is just relative to the current index space contents

Luke Wagner (May 18 2020 at 16:24):

(answering why not a separate index space per class of type:) i think that could be an isomorphic alternative; you'd basically have to put the "what class of type is this" next to the index. with the current design (already in the MVP), the "what class of type is this" enum is part of the typedef itself

Alex Crichton (May 18 2020 at 16:25):

e.g. call_indirect always looks up in the function type index space, not the module type index space

Alex Crichton (May 18 2020 at 16:25):

Luke Wagner (May 18 2020 at 16:25):

Alex Crichton (May 18 2020 at 16:26):

Luke Wagner (May 18 2020 at 16:26):

Alex Crichton (May 18 2020 at 16:26):

Luke Wagner (May 18 2020 at 16:27):

so $typeindex is (eventually) one of {function, struct, array, module, instance, ...}, which isn't a reference to the thing, but the thing itself

Luke Wagner (May 18 2020 at 16:27):

and (ref $typeindex) is building a new type, which is a reference to the thing

Alex Crichton (May 18 2020 at 16:27):

not sure I fully understand but "wave hands gc changes things" is good enough for me for now

Luke Wagner (May 18 2020 at 16:28):

a different example, in interface types-land is when you have (record (field "x" $sometype))

Luke Wagner (May 18 2020 at 16:28):

(in this case there's no reference, it's just a record value embedding some other value as a field)

Alex Crichton (May 18 2020 at 16:29):

Luke Wagner (May 18 2020 at 16:30):

it's just explicitly called out b/c there is currently only one class of typedef

Alex Crichton (May 18 2020 at 16:30):

Luke Wagner (May 18 2020 at 16:30):

Alex Crichton (May 18 2020 at 16:31):

I just don't fully understand how gc changes things to require one index space as opposed to multiple type index spaces

Luke Wagner (May 18 2020 at 16:31):

Alex Crichton (May 18 2020 at 16:31):

Luke Wagner (May 18 2020 at 16:31):

the "function" index space isn't a space of types, it's a space of function definitions

Alex Crichton (May 18 2020 at 16:32):

right yeah, but with module types I don't know why we don't rename the type index space to "function type" index space

Alex Crichton (May 18 2020 at 16:32):

you're mentioning because of gc (ref $ty) things, but I don't fully get that, but that's also ok I don't really need to at this point

Luke Wagner (May 18 2020 at 16:32):

i guess b/c we've already planned to have a single index space, discriminating with the 0x60 prefix code

Alex Crichton (May 18 2020 at 16:32):

Luke Wagner (May 18 2020 at 16:32):

in some cases, yes, but in other cases, i think you need the discriminant in one place or the other

Luke Wagner (May 18 2020 at 16:33):

e.g., function definitions can only refer to function types, so yeah, there it's extra checking

Luke Wagner (May 18 2020 at 16:33):

Luke Wagner (May 18 2020 at 16:34):

Alex Crichton (May 18 2020 at 16:34):

Alex Crichton (May 18 2020 at 16:36):

I don't really understand much about it other than "it can refer to parent stuff"

Luke Wagner (May 18 2020 at 17:00):

(sorry meetings) yeah, alias lets you inject a definition in either (1) your parent, (2) the export of an imported or nested instance

Luke Wagner (May 18 2020 at 17:00):

Alex Crichton (May 18 2020 at 17:02):

Luke Wagner (May 18 2020 at 22:57):

Generalize Module Types to Module Linking by lukewagner · Pull Request #3 · WebAssembly/module-types

As is, the Module Types proposal tweaks the spec-internal definition of module/instance types and gives them a text format so that module/instance types can be used in toolchains, but there are no ...

Alex Crichton (May 18 2020 at 23:41):

@Luke Wagner can you give an example of what you're thinking with an alias referring to something in the enclosing module?

Alex Crichton (May 18 2020 at 23:44):

It also feels a bit odd to have so many alias/instance sections, do you think it'd be possible to fold alias definitions into the instance section? The same idea just a different binary structure where the instance section would be a bit more "meaty". Each element in the instance section would either instantiate a module or create an alias for a previous instance.

Alex Crichton (May 18 2020 at 23:44):

Alex Crichton (May 18 2020 at 23:46):

So the intention is that (alias $name (func $instance $fname)) -- $name is the name of the function we're creating (optional), $instance is an instance index, and $fname, is that encoded as "fname" the string or an index where it's the nth exported function (or nth export?) of $instance?

Luke Wagner (May 19 2020 at 00:15):

For the first question: the reason for aliases referring to the outer module is just to remove redundancy; in package linking scenarios, the same module/instance types get repeated a ton.

Luke Wagner (May 19 2020 at 00:21):

For the second: yeah, that was the alternative I liked for a while. The thing that's a bit odd about it is that an alias in the instance section doesn't add a new kind of instance, so it's not really the "instance" section but the "instance and alias of instance exports" section. Aliases are a bit like Imports, so it seems vaguely symmetric to give them their own section. But it's not like that's the only way to do it.

Luke Wagner (May 19 2020 at 00:21):

For the third: yes, that's right. $fname is an index into the exports array of $instance's type definition (which is local tot he module)

Alex Crichton (May 19 2020 at 02:30):

@Luke Wagner oh referring to the parent makes sense, I was wondering if you had thoughts on the binary format? If aliases can only refer to exports you can't define exports before instantiating right? I'm just murky on how the specifics of semantics and binary encoding would work

Luke Wagner (May 19 2020 at 03:26):

@Alex Crichton Aliases can refer to any type/module defs in the parents' index spaces, not just exports. It's only aliases to nested instances that can only refer to exports

Alex Crichton (May 19 2020 at 16:22):

Luke Wagner (May 19 2020 at 16:32):

Looking at importdesc, one could reconsider the existing 0x00 case from always being a func to instead being "whatever the indexed type is", so that as soon as you add module/instance types, the 0x00 can refer to them just as well as func. E.g., that's what (ref $typeIndex) will do

Luke Wagner (May 19 2020 at 16:33):

Luke Wagner (May 19 2020 at 16:38):

Different, but perhaps-more-justifiable bikeshed: in the Alias section, for the parent aliases, could the second byte of module be 0x04 (to match import and export)?

Alex Crichton (May 19 2020 at 16:40):

that's indexing within your parent's module index space, right? not your parent's export index space?

Luke Wagner (May 19 2020 at 16:41):

Alex Crichton (May 19 2020 at 16:41):

Luke Wagner (May 19 2020 at 16:41):

also great idea with using (parent $x) as the text format, i'm going to update the Explainer to match

Alex Crichton (May 19 2020 at 16:42):

I do want to document the text form at as well, but I'll probably do that in tandem with writing the text parser

Luke Wagner (May 19 2020 at 16:42):

One other tweak: in components, I think there aren't any Table, Memory or Global sections allowed, so perhaps you can explicitly say these are disallowed

Alex Crichton (May 19 2020 at 16:43):

table/global makes sense, but for memory, do you mean no defined memory, but you can still import memory, right?

Alex Crichton (May 19 2020 at 16:43):

Luke Wagner (May 19 2020 at 16:44):

yes, you can still alias all of the memories/tables/globals of nested instances

Alex Crichton (May 19 2020 at 16:44):

Luke Wagner (May 19 2020 at 16:45):

one last change: i think, unlike the core section rules, we can allow the Function section to be intermingled with the Instance/Module/Type sections

Luke Wagner (May 19 2020 at 16:46):

Alex Crichton (May 19 2020 at 16:46):

Luke Wagner (May 19 2020 at 16:46):

i thought about it a lot for core modules and i think it needs the stricter separation

Luke Wagner (May 19 2020 at 16:47):

part of what makes it make sense for adapter functions is that component instances are (mostly, get to that in a sec) stateless

Luke Wagner (May 19 2020 at 16:47):

so we can say that the component instance is created before its nested instances

Luke Wagner (May 19 2020 at 16:47):

the one bit of state a component instance has is: which of my nested instances have been created

Alex Crichton (May 19 2020 at 16:47):

Luke Wagner (May 19 2020 at 16:47):

so what we can say is that it is a dynamic error to call an export of an instance that hasn't been created

Luke Wagner (May 19 2020 at 16:48):

Alex Crichton (May 19 2020 at 16:48):

Luke Wagner (May 19 2020 at 16:48):

Luke Wagner (May 19 2020 at 16:49):

there is that subtle detail of are A's exports visible if A's start function calls the adapter function

Alex Crichton (May 19 2020 at 16:50):

Luke Wagner (May 19 2020 at 16:50):

i think for now we can say "yes", and then later talk about the "after start" function thing later

Luke Wagner (May 19 2020 at 16:50):

b/c import adapters definitely need to be able to reenter the core module caller, to call malloc()

Alex Crichton (May 19 2020 at 16:51):

Build software better, together

GitHub is where people build software. More than 50 million people use GitHub to discover, fork, and contribute to over 100 million projects.

Luke Wagner (May 19 2020 at 16:52):

in that case, you might want to add a caveat to the version word noting that the 0x1 is only for components

Alex Crichton (May 19 2020 at 16:52):

oh sorry yeah this is sort of like a diff of what we expect to land in wasmparser

Alex Crichton (May 19 2020 at 16:52):

Luke Wagner (May 19 2020 at 16:53):

Luke Wagner (May 19 2020 at 17:02):

do you mind if i resolve your open conversations in the Module Linking PR? or happy for you to comment on them

Alex Crichton (May 19 2020 at 17:04):

Luke Wagner (May 19 2020 at 17:50):

haha, no worries, i was making progress on other discussions in the PR, so no waiting. i was just tidying up since it's looking like we're almost done. i'm still going to present at the next CG meeting before merging, i think

Luke Wagner (May 19 2020 at 17:50):

Luke Wagner (May 19 2020 at 18:07):

btw, i was working through an example with transitive dependencies to see how the link step would work. my main interest was finding a scheme whereby the generated Linked Module simply imports unmodified Packaged Modules and avoiding the module type of a given Packaged Module needing to capture all of its transitive dependencies in its module type. i ended up finding a wrapping scheme that uses nested modules and parent aliases to essentially "curry" module imports: https://gist.github.com/lukewagner/d662cbe7b58281672053dab4118d25b7

Luke Wagner (May 19 2020 at 18:08):

Alex Crichton (May 20 2020 at 23:13):

(type $t (instance (export "x" (instance (type $t)))))

Alex Crichton (May 20 2020 at 23:13):

Alex Crichton (May 20 2020 at 23:14):

or something like for the text format we have to figure out a DAG of how to visit type definitions

Alex Crichton (May 20 2020 at 23:17):

I'm assuming we're doing the same thing for instances as we do for functions, which is when you declare the type you can specify both the (type xx) reference as well as the type inline (e.g. (func (type 0) (param i32)))

Alex Crichton (May 20 2020 at 23:17):

Alex Crichton (May 20 2020 at 23:18):

(type $t (instance
  (export "x" (instance (type $t)
    (export "x" (instance (type $t)
      (export "x" (instance (type $t)
        (export "x" (instance (type $t)
          (export "x" (instance (type $t)
            (export "x" (instance (type $t)
            (export "x" (instance (type $t)))
            ))
          ))
        ))
      ))
    ))
  ))
))

Alex Crichton (May 20 2020 at 23:19):

but validating that at the text level isn't really easy to do because as we're determining the canonical value for $t we need to know what $t is to compare it to $t

Alex Crichton (May 20 2020 at 23:19):

we can perhaps solve this by saying "don't do the function thing, you say the index or you say the inline, not both"

Alex Crichton (May 20 2020 at 23:20):

well so let me rephrase, this seems like it could either be a binary error or a text error

Alex Crichton (May 20 2020 at 23:21):

Luke Wagner (May 20 2020 at 23:59):

Haha, yes, I think no recursive types for now. Perhaps just by requiring all type indices refer to earlier typedefs

Luke Wagner (May 21 2020 at 00:02):

Also, agreed that if you write (instance (type $T)) you shouldn't need to be able to re-state all the exports/imports

Luke Wagner (May 21 2020 at 00:03):

That's really just a goofy special case for functions so they can assign identifiers to parameters

Luke Wagner (May 21 2020 at 00:04):

Actually, for directly-embedded type definitions like you're showing, I think no circularity forever; the only exception is circularity via (ref $T)

Alex Crichton (May 21 2020 at 00:24):

@Luke Wagner ok sounds good, I'll need to write some sort of sorting pass in the text parser then too to do a topological sort

Luke Wagner (May 21 2020 at 00:25):

Alex Crichton (May 21 2020 at 00:49):

thinking more on it, you're right, I think the text format should impose the restriction itself

Alex Crichton (May 21 2020 at 22:30):

@Luke Wagner here's another interesting thing to think about, so right now you can specify imports/exports inline in the text format, e.g. these are all the same

(func $f)
(export "" (func $f))
(func $f (export ""))

(import "" "" (func $f))
(func $f (import "" ""))

Alex Crichton (May 21 2020 at 22:30):

for nested modules, however, the proposed syntax you've got so far doesn't support this

Alex Crichton (May 21 2020 at 22:30):

Alex Crichton (May 21 2020 at 22:31):

(nested-module (type $ty) (module ...))

Alex Crichton (May 21 2020 at 22:31):

and (module ...) bare is sugar for auto-calculating the type, inserting it into the type index space, and not having any implicit imports/exports

Alex Crichton (May 21 2020 at 22:32):

I was also wondering how you'd do something like (module (type $module_type) ...) b/c that's also ambiguous

Alex Crichton (May 21 2020 at 22:32):

but at least for printing the binary format we'll need a way to say "the module type was specified at this index, don't inject anything else"

Luke Wagner (May 21 2020 at 22:37):

Luke Wagner (May 21 2020 at 22:38):

i would think (module ...) would be mostly symmetric to (func ...) in the ways you mentioned (import, export, explicit type index)

Luke Wagner (May 21 2020 at 22:39):

i see your point that it'd be necessary to scan the whole body of (module ...) to determine the module type, unlike (func ...) which tells you that basically up-front

Luke Wagner (May 21 2020 at 22:40):

but i think there's still symmetry with func in that, to validate the body of a (func ...), you have to have parsed all the types of all the other functions first (so that you know all the funcs' types)

Alex Crichton (May 21 2020 at 22:47):

(module
  (module (export "x"))
)

Alex Crichton (May 21 2020 at 22:47):

(module
  (type (module))
  (module (type 0))
)

Alex Crichton (May 21 2020 at 22:47):

Alex Crichton (May 21 2020 at 22:48):

basically everything in parsing only requires 1 lookahead right now, but those would otherwise require multiple tokens of lookahead

Alex Crichton (May 21 2020 at 22:48):

Luke Wagner (May 22 2020 at 16:44):

Ohhhhh, I finally get your meaning; you're saying: when I see the tokens ( module ( export, I don't know if I'm parsing an export of the module definition, or declaring that this module definition is exported. I was thinking of it as an already-parsed AST which is after this question has been sorted :)

Alex Crichton (May 22 2020 at 16:47):

Luke Wagner (May 22 2020 at 16:48):

So I suppose in both cases, the (export "x") and (type 0) require a constant amount of lookahead to see what they are

Alex Crichton (May 22 2020 at 16:48):

that's why I was thinking of (nested-module ...) because that would put you in a parsing context where you clearly know what's what

Alex Crichton (May 22 2020 at 16:48):

Luke Wagner (May 22 2020 at 16:49):

Alex Crichton (May 22 2020 at 16:49):

Luke Wagner (May 22 2020 at 16:49):

well it's a good question, i'll file an issue on the repo after we merge the linking PR (i'm thinking mid next week)

Alex Crichton (May 22 2020 at 16:50):

Luke Wagner (May 22 2020 at 16:50):

Alex Crichton (May 22 2020 at 20:56):

Hm ok so I'm getting really tripped up how to implement alias statements in text parsing

Alex Crichton (May 22 2020 at 20:56):

Alex Crichton (May 22 2020 at 20:57):

1) expand inline imports/exports
2) expand inline type annotations to actual type declarations
3) record what index each name is at
4) fill in all names with their indexes

Alex Crichton (May 22 2020 at 20:57):

during step (4) we also have this extra "validate the inline function type matches the referenced type" if you do something like (func (type 0) (param i32))

Alex Crichton (May 22 2020 at 20:57):

Alex Crichton (May 22 2020 at 20:58):

(module
  (type (module))
  (module (type 0))
)

Alex Crichton (May 22 2020 at 20:58):

so when the module type isn't listed, we need to calculate it an inject it as a module type

Alex Crichton (May 22 2020 at 20:58):

because that needs information from the parent, which if we're only in step (2) we don't even have symbolic names yet

Alex Crichton (May 22 2020 at 20:58):

much less stable indexes because we're still injecting new type annotations depending on what we're seeing

Alex Crichton (May 22 2020 at 20:59):

(module
  (module
    (alias (parent (type 0)))
    (func (type 0) (param i32))
  )
)

Alex Crichton (May 22 2020 at 20:59):

the definition of the parent module's type 0 is going to be the type of the inlined module

Alex Crichton (May 22 2020 at 21:00):

Alex Crichton (May 22 2020 at 21:01):

I don't know if I should just throw everything out and start from scratch with a complicated resolver

Alex Crichton (May 22 2020 at 21:01):

Alex Crichton (May 22 2020 at 21:02):

I can't tell if all this elaboration/name resolution has to happen in cycles till it reaches some sort of fixed point or otherwise what the precise order of passes is to figure everything out correctly

Alex Crichton (May 22 2020 at 21:05):

(module
  (module
    (alias (parent (type $foo)))
    (func (type 0))
  )
  (type $foo (func))
)

I don't know what order to do things. The index of $foo is 1, but we don't know that until the type of the nested module is elaborated. We can't do that though until we figure out what it's parent reference is pointing to

Luke Wagner (May 22 2020 at 21:17):

@Alex Crichton So for the text format parsing, my inclination would be to say that, when you see an explicit type declaration, you simply bake in that index, no questions asked; if the module fails to validate, it's the author's fault

Alex Crichton (May 22 2020 at 21:17):

Alex Crichton (May 22 2020 at 21:18):

this is more just about trying to do name resolution where we're figuring out what indexes are assigned to everything

Alex Crichton (May 22 2020 at 21:20):

(module
  (type $foo (instance
    (export "" (func $bar))
  ))
  (module
    (alias (parent (type $foo)))
    (import "" (instance $i (type 0)))
    (alias ($i (func $bar)))
    (func
      call 0)
  )
)

Luke Wagner (May 22 2020 at 21:23):

So one thing we can do for now (and perhaps forever) is to say that aliases can only refer to preceding definitions

Alex Crichton (May 22 2020 at 21:24):

Alex Crichton (May 22 2020 at 21:25):

(alias ($i (func $bar))) realizes that $i resolves to local instance 0, which is imported, which has a type defined locally, but that type was aliased from a parent module

Alex Crichton (May 22 2020 at 21:25):

like these are kind of "dumb concerns" in that they're only really applicable to the implementation of a text parser and don't really have many implications on the binary format

Alex Crichton (May 22 2020 at 21:26):

I'm tripping myself up so much because the text format is so simple today and I can't figure out how to make the addition of modules as simple as it is right now

Alex Crichton (May 22 2020 at 21:26):

without having things like global name resolution and tombstones for "this'll get resolved later" and things like that

Luke Wagner (May 22 2020 at 21:26):

Yeah, I think the text parser has to maintain a stack of identifier scopes (one per nested module) that it updates in a linear pass over the AST

Luke Wagner (May 22 2020 at 21:27):

I suppose what this means is that some identifiers (e.g., calls to $functions in function bodies) get resolved at the end (b/c they are allowed to be circular), while some get filled in as part of a linear pass

Alex Crichton (May 22 2020 at 21:27):

Alex Crichton (May 22 2020 at 21:28):

the text format is super loose today in that you just throw things in a soup and a valid module almost always pops out

Alex Crichton (May 22 2020 at 21:28):

but this is starting to place lots of restrictions of "no everything has to be very strictly ordered"

Luke Wagner (May 22 2020 at 21:28):

well, i think every identifier that exists today would be in this "fill in at the end when all identifiers are known" category,

Luke Wagner (May 22 2020 at 21:30):

and we're just introducing a new "kind" of identifier that gets resolved in a new, earlier, linear pass

Alex Crichton (May 22 2020 at 21:30):

it feels wrong to have "oh these identifiers work only linearly" and "oh but those identifiers can work anywhere"

Alex Crichton (May 22 2020 at 21:31):

and I can't figure out how to prove "yes the linear stuff is required due to this design constraint"

Luke Wagner (May 22 2020 at 21:32):

heh, i guess that's sortof the case with C++; in struct C { typedef int X; X foo() { bar(); } X bar() { foo(); }, the names bar() and foo() can be cyclic whereas the reference to X has to be in order

Alex Crichton (May 22 2020 at 21:33):

Luke Wagner (May 22 2020 at 21:34):

But yeah, I see what you mean, the current parse rules simply parse every field in isolation and then do name resolution as a wholly separate, order-independent pass

Luke Wagner (May 22 2020 at 21:46):

Trying to think a bit more about what the general rule is, I think it's this: you do most name resolution in a linear pass, and any time a name is un-resolved:

Then, in a second pass, go over the placeholders and check that they resolve to a name and that name is not an alias or instance definition

Thus, only name cycles involving aliases or instance definitions would be disallowed; everything else should get resolved as it is today

Alex Crichton (May 22 2020 at 23:05):

I think that sounds reasonable, yeah, I got further today in implementing all this, I think this is the last step for the text format

Alex Crichton (May 22 2020 at 23:05):

Alex Crichton (May 26 2020 at 21:12):

I'm definitely getting from the point that wat was previously a pretty simple parser with a single pass to resolve names, but now it's becoming more of a compiler almost where it's got a type resolutoin pass and such

Alex Crichton (May 26 2020 at 21:13):

(module $outer
  (module $inner
    (module $child (export "a"))
  )
)

(module $outer
  (type $child_type (module))
  (type $inner_type (module
    (export "a" (module (type $child_type)))
  ))

  (module $inner (type $inner_type)
    (alias $child_type_inner (parent (type $child_type)))
    (module $child (type $child_type_inner))
    (export "a" (module $child))
  )
)

Luke Wagner (May 26 2020 at 21:23):

Yeah, that looks right, and yes, I can see how this makes the text-to-binary a lot more complicated

Alex Crichton (Jun 01 2020 at 19:09):

@Luke Wagner (export $some_instance) is only intended to be sugar for the text format, right? not reflected in the binary format?

Luke Wagner (Jun 01 2020 at 19:29):

Good question! For now: yes. At some point in the future, when one can import instances of imported instance types (O_O), they may need to become first-class things b/c it won't be possible to desugar them at text-to-binary time

Dan Gohman (Jun 01 2020 at 23:14):

Dan Gohman (Jun 01 2020 at 23:15):

Dan Gohman (Jun 01 2020 at 23:17):

And as a related question, in theory commands could have immutable global exports, which could be a way for commands to export metadata, however without the ability to export strings or other higher-level types, that may not be very valuable.

Luke Wagner (Jun 01 2020 at 23:26):

Good question! Coincidentally I was just thinking about this and how it might work for stuff like metadata. It seems like one could have, as a component import/export an interface value (not const global, just a pure value) and this could be lowered into a core const global import, and this could allow one to import compound JSONesque values

Luke Wagner (Jun 01 2020 at 23:27):

Dan Gohman (Jun 01 2020 at 23:32):

Ah, and by being a value export, rather than a global export, you'd read it with an adapter function, and not with global.get

Luke Wagner (Jun 01 2020 at 23:34):

Alex Crichton (Jun 10 2020 at 22:15):

(module
  (import "" (module))
  (type (module)))

Alex Crichton (Jun 10 2020 at 22:15):

Alex Crichton (Jun 10 2020 at 22:16):

but with the first 5 sections in any order, it's unclear what the text format is supposed to do here in that regard

Alex Crichton (Jun 10 2020 at 22:16):

(module
  (type (module)) ;; injected
  (import "" (module (type 0)))
  (type (module)) ;; original type annotation
)

Alex Crichton (Jun 10 2020 at 22:16):

(module
  (type (module)) ;; original annotation reordered first
  (import "" (module (type 0)))

Alex Crichton (Jun 10 2020 at 22:17):

I suppose I'm answering my question as I'm writing this down, it basically has to be the former

Alex Crichton (Jun 10 2020 at 22:17):

Luke Wagner (Jun 10 2020 at 23:04):

Yeah, good question. So in the analogous function situation, when the inline type def goes before the explicit type def... do you get two type defs or 1?

Luke Wagner (Jun 10 2020 at 23:04):

Luke Wagner (Jun 10 2020 at 23:12):

By my reading, an inline func type followed by explicit func type def will produce two type defs: only inline funcs "reach back"; type defs don't

Luke Wagner (Jun 10 2020 at 23:13):

Luke Wagner (Jun 10 2020 at 23:14):

Luke Wagner (Jun 10 2020 at 23:15):

Alex Crichton (Jun 10 2020 at 23:15):

Luke Wagner (Jun 10 2020 at 23:15):

well, practically speaking, i'd do whatever was easiest for now, but if it's the former, i wouldn't feel bad about it

Alex Crichton (Jun 10 2020 at 23:17):

order of items previously in the text format have largely been irrelevant, but with the 5 sections at the front that can be all interleaved I think it's a lot more imporatnt now

Alex Crichton (Jun 10 2020 at 23:17):

so I don't think there's actually any opiton other than the first, injecting a duplicate annotation

Alex Crichton (Jun 10 2020 at 23:18):

Alex Crichton (Jun 12 2020 at 19:35):

Initial implementation of module linking by alexcrichton · Pull Request #26 · bytecodealliance/wasm-tools

This commit is the initial implementation of the module linking proposal in the three tooling crates of this repository. Unfortunately this is just one massive commit which isn't really able to...

Stream: wasm

Topic: modules types binary format

Alex Crichton (May 18 2020 at 16:08):

Alex Crichton (May 18 2020 at 16:09):

Alex Crichton (May 18 2020 at 16:09):

Alex Crichton (May 18 2020 at 16:09):

Alex Crichton (May 18 2020 at 16:09):

Luke Wagner (May 18 2020 at 16:14):

Alex Crichton (May 18 2020 at 16:15):

Luke Wagner (May 18 2020 at 16:15):

Alex Crichton (May 18 2020 at 16:15):

Alex Crichton (May 18 2020 at 16:15):

Alex Crichton (May 18 2020 at 16:16):

Alex Crichton (May 18 2020 at 16:16):

Alex Crichton (May 18 2020 at 16:16):

Alex Crichton (May 18 2020 at 16:16):

Alex Crichton (May 18 2020 at 16:16):

Luke Wagner (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:17):

Luke Wagner (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:17):

Alex Crichton (May 18 2020 at 16:18):

Luke Wagner (May 18 2020 at 16:18):

Luke Wagner (May 18 2020 at 16:18):

Luke Wagner (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:19):

Luke Wagner (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:19):

Luke Wagner (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:19):

Alex Crichton (May 18 2020 at 16:20):

Alex Crichton (May 18 2020 at 16:20):

Alex Crichton (May 18 2020 at 16:20):

Luke Wagner (May 18 2020 at 16:20):

Luke Wagner (May 18 2020 at 16:20):

Alex Crichton (May 18 2020 at 16:21):

Alex Crichton (May 18 2020 at 16:21):

Luke Wagner (May 18 2020 at 16:23):

Luke Wagner (May 18 2020 at 16:24):

Alex Crichton (May 18 2020 at 16:25):

Alex Crichton (May 18 2020 at 16:25):

Alex Crichton (May 18 2020 at 16:25):

Luke Wagner (May 18 2020 at 16:25):

Luke Wagner (May 18 2020 at 16:25):

Alex Crichton (May 18 2020 at 16:26):

Luke Wagner (May 18 2020 at 16:26):

Alex Crichton (May 18 2020 at 16:26):

Luke Wagner (May 18 2020 at 16:27):

Luke Wagner (May 18 2020 at 16:27):

Alex Crichton (May 18 2020 at 16:27):

Luke Wagner (May 18 2020 at 16:28):

Luke Wagner (May 18 2020 at 16:28):

Luke Wagner (May 18 2020 at 16:28):

Alex Crichton (May 18 2020 at 16:29):

Luke Wagner (May 18 2020 at 16:30):

Luke Wagner (May 18 2020 at 16:30):

Alex Crichton (May 18 2020 at 16:30):

Luke Wagner (May 18 2020 at 16:30):

Alex Crichton (May 18 2020 at 16:31):

Luke Wagner (May 18 2020 at 16:31):

Alex Crichton (May 18 2020 at 16:31):

Luke Wagner (May 18 2020 at 16:31):

Alex Crichton (May 18 2020 at 16:32):

Alex Crichton (May 18 2020 at 16:32):

Luke Wagner (May 18 2020 at 16:32):

Alex Crichton (May 18 2020 at 16:32):

Luke Wagner (May 18 2020 at 16:32):

Luke Wagner (May 18 2020 at 16:32):

Luke Wagner (May 18 2020 at 16:33):

Luke Wagner (May 18 2020 at 16:33):

Luke Wagner (May 18 2020 at 16:34):

Luke Wagner (May 18 2020 at 16:34):

Alex Crichton (May 18 2020 at 16:34):

Alex Crichton (May 18 2020 at 16:36):

Alex Crichton (May 18 2020 at 16:36):

Luke Wagner (May 18 2020 at 17:00):

Luke Wagner (May 18 2020 at 17:00):