Binary format in overview?

[takikawa]

Currently the binary format is left TODO, I was wondering if it makes sense to fill any of this in yet, or whether the proposal needs more design before that. (I'm interested in prototyping it)

For example, based on the interpreter branch something like the following could be added to the binary format section for just the type imports part (didn't include anything about private for now).

Binary Format

Imports / Exports

External Kind

The following external kind is added:

• 5 indicating a Type import

Import section

The import section is extended to include type imports by extending animport_entry as follows:

If the kind is Type:

Field	Type	Description
type	type_type	the type being imported

Export section

The export section is extended to reference type imports by extending an export_entry as follows:

If the kind is Type:

Field	Type	Description
type	heap_type (s33)	a heap type to export (as type indices are heap types, can also be an index)

Type type

Each type_type has the fields:

Field	Type	Description
import_kind	u8	The kind of a type import
bound	heap_type (s33)	The heap type that is a bound for the type import

An import_kind can take the following values:

Name	Value	Description
Eq	0	An import exactly matching the bound
Sub	1	An import that is a subtype of the bound

[rossberg]

Thanks, done, see #15. But note that some bits still require some resolution, in particular, how we enforce def-use ordering between type and import sections.

I also remove Eq constraints from the above, since it's not currently in the overview, until it's clear that they're truly useful. Without the GC proposal, they probably aren't.

[takikawa]

Thanks for merging that!

But note that some bits still require some resolution, in particular, how we enforce def-use ordering between type and import sections.

That's helpful to know, thanks, I had been wondering how this would work since it even comes up for the example in the overview I think (with $File getting imported after the $read3 signature).

[SNSTRUTHERS]

Would adding a separate type kind in the types section be a reasonable place to put private type definitions? At present all function signatures in the type section must be prefixed by a 0x60 byte in the binary format. Maybe we could add a 0x5f for private types?