Text format: type definition abbreviations

[tlively]

Since we write a lot of text format tests in Binaryen, we've implemented a number of abbreviations to make type definitions shorter. Here's the grammar I've implemented the new Binaryen parser that combines the text format used in this repo with the abbreviations used in Binaryen.

deftype ::= '(' 'rec' subtype* ')'
          | subtype

subtype ::= '(' 'type' id? '(' 'sub' typeidx? strtype ')' ')'
          | '(' 'type' id? strtype ')'

strtype ::= functype
          | structtype
          | arraytype

functype ::= '... ;; same as MVP

structtype ::= '(' 'struct' field* ')'

arraytype ::= '(' 'array' field ')'

field ::= '(' 'field' id? fieldtype ')'
        | '(' 'field' fieldtype* ')'

fieldtype ::= storagetype
            | '(' 'mut' storagetype ')'

storagetype ::= valtype | packedtype

packedtype ::= 'i8' | 'i16'

Comments and suggested edits welcome. Once it looks good, we should document it in the MVP doc. For the actual spec, we'll have to extract the abbreviations from the grammar and turn them into rewrite rules.

[sbc100]

What is strtype? Presumably nothing to do with strings, but it certainly reads like it is. Maybe a better name?

[tlively]

strtype is short for "structural type" and comes directly from the proposal docs: https://github.com/WebAssembly/gc/blob/main/proposals/gc/MVP.md#type-definitions. I agree it would be nice to find a clearer name or abbreviation for those, but I do want to keep the explanation of the text format in sync with the abstract syntax.

[rossberg]

Actually, strtype stands for "structured type", i.e., a compound type like structs, funcs, arrays, as opposed to scalar types like ints and floats.

[tlively]

There is also the issue of using symbolic references to struct fields, as discussed here: #193 (comment). I don't believe Binaryen's parser currently allows symbolic field references, but I agree they would be nice to have. Since we ended up keeping the type annotations on struct.get and friends, we could keep the dependent name lookup behavior where each struct type gets its own index space of types. @rossberg, wdyt? What if separate definitions of the same type contain conflicting field names?

[rossberg]

We could, but personally, I don't find it worth the added complexity. Currently, conflicting field symbols are simply an error, so you prefix them to disambiguate, like in assembly and the good old C days. : )

[tlively]

We should consider allowing un-prefixed names to be a requirement to make debugging in browser devtools more feasible. Binaryen supports this today (although it doesn’t allow using field names symbolically in the text), so losing this capability would regress the debugging experience. As we get closer to productionizing WasmGC, debugging has become an important area of user concern.

[rossberg]

Binaryen supports this today (although it doesn’t allow using field names symbolically in the text)

I'm confused, where does it support them then?

[tlively]

Field names in type definitions are parsed and end up in the names section, but the parser doesn’t support using those names as field indices in instructions.

[titzer]

Now that we've settled on keeping an immediate for both the struct index and the field index for struct.get and struct.set, it seems logical to me for the text format to reflect that. In particular, a standard two-level namespace of struct names and field names e.g. $S.$f in the text format seems convenient and would have less surprise for most users than requiring field name disambiguation via manual prefixing.

[tlively]

I filed #361 to continue the discussion about whether we should have dependent field name lookup.

As promised, here are some examples of the abbreviations I suggested allowing in the opening post. Most are probably uncontroversial.

;; maximal type definition
(rec (type (sub (struct (field i32) (field i64)))))

;; abbreviate out singleton rec group
(type (sub (struct (field i32) (field i64))))

;; abbreviate out declaration of zero supertypes
(type (struct (field i32) (field i64)))

;; combine field declarations
(type (struct (field i32 i64)))

;; abbreviate out 'field' -- note: no longer allowed
(type (struct i32 i64))

[rossberg]

These all sound good to me and are already supported by the interpreter. The only exception is the last one, which I'm a bit skeptical about. It has no real parallel anywhere else so far, and it might become a debt when we later want to add more elements to struct declarations (e.g. descriptors or static fields like we discussed).