Continuation type encoding

[dhil]

This is a tracking issue to continue the discussion in #89.

We can encode the type (cont $ft) in different ways. The interesting part is the encoding of the type index $ft. Some possible ways we can encode the type index:

• as a u32,
• as a zero-valued u8 followed by a u32,
• or as a s33.

The latter two options give a natural "extension" point, enabling us to attach additional metadata to continuation types in the future.

[fgmccabe]

IIRC, negative type indices are reserved for 'standard' tyoes. While at the moment we don't have any standard continuation types, I think it is prudent to not shut out that potential for the future. Hence, I support s33.

[tlively]

I still prefer using u32 or 0x00 u32 because this is syntactically a type index (i.e. a typeidx, the existing syntactic element encoded as a u32), not an arbitrary heap type (i.e. a heaptype, the existing syntactic element encoded as an s33). It seems very unlikely that we would ever want to use an abstract heap type (this is probably what @fgmccabe meant by "standard type") in this position, so the extra generality of using heaptype does not seem warranted. I'd also prefer to reuse the existing practice of inserting a 0x00 to serve as a future extension point rather than use s33 for this purpose, which I don't believe has precedent.

[rossberg]

@tlively, the room for possible future extensions is a bit broader than that. For example, in all places where we use s33 as part of a larger type expression, we could consistently allow inlining type definitions in the future, such that e.g. not every one-off composite type needs to be its own definition. It's a code "hygiene" consideration related to keeping all type codes different, even where they inhabit disjoint spaces today, so that they can still be regrouped later.

[tlively]

Sure, but we still currently use s33 only where abstract heap types or numeric types would be allowed. We also don’t use s33 as an expansion point for any other kind of index.