Use `typeuse` in text format?

[tlively]

The current explainer does not explicitly explain the text format for this proposal, but I propose that the text format for continuation type definitions be updated to this:

comptype_I ::= ... | '(' 'cont' (x,I'):typeuse_I ')' => (cont x), I'

Using the existing typeuse production and its abbreviation would allow all of these to be well-formed and valid:

(module
  (type $f (func (param i32) (result i32))
  (type $k1 (cont (type $f)))
  (type $k2 (cont (type $f) (param i32) (result i32))) ;; Same as $k1
  (type $k3 (cont (param i32) (result i32))) ;; Same as $k1 and $k2
  (type $k4 (cont (param i64) (result i64))) ;; Implicitly defines a new function type
  (type $k5 (cont)) ;; Implicitly defines a new function type
)

Notably the current text format (type $k (cont $f)) would no longer be correct, but the advantage would be that writing tests would become much simpler because the function types would not need to be separately defined. (This is about the text format only; the function type definition would still be separate in the binary format and abstract syntax.)

[rossberg]

I agree that we should allow this syntax, both for consistency and convenience. We could additionally allow the current syntax as a shorthand, but perhaps that's not worth it.

[tlively]

Oh, it looks like the interpreter already uses typeuse here. It just also allows the "current" syntax as sugar, and the parsing of inline types is broken:

https://github.com/WebAssembly/stack-switching/blob/5ef83f2/interpreter/text/parser.mly#L439

[tlively]

Yikes, it turns out that using implicit type definitions can't work out anyway. Since the implicitly defined function types are inserted at the end of the type section, continuation type definitions that refer to them would have invalid forward references to future types. So $k2 through $k5 in the opening post actually are not valid.

[rossberg]

Ah, bummer. Yeah, so I believe the implicit shorthand will work, but only if a function type of that shape is already defined:

(type (func (param i32)))
(type (cont (param i32)))  ;; ok, picks up previous type
(type (cont (param i64)))  ;; not ok, desugars into forward use

Unfortunately, I don't think there is much we can do about that. Inserting the synthesised types anywhere but at the end would (a) be complicated, and (b) break uses of a non-symbolic type indices.

So IDK, we might still want the shorthand for consistency, but its usability is gonna be "surprising".