Text syntax of "refines" may be somewhat nonstandard

[alexcrichton]

I believe currently the intended syntax for "refines" is something along the lines of:

(type $the_variant (variant 
  (case "x" unit)
  (case "y" unit (refines "x"))
))

Where the binary format for this is:

case          ::= n:<name> t:<valtype> 0x0             => (case n t)
                | n:<name> t:<valtype> 0x1 i:<u32>     => (case n t (refines case-label[i]))

Personally I find this to be a bit of a discrepancy where in the text format a string is used ("x" above) and in the binary format an integer is used (the index of the case). This means that a text-to-binary and a binary-to-text implementation have to otherwise keep track of this information. For example implementing a text-to-binary translation means that the tool must perform resolution over the string names of each variant. Currently I don't think text-to-binary tools perform resolution over any string names at all, only over indexes (like $x). Additionally binary-to-text transforms may parse name sections to assist with printing debugging information throughout the text format but otherwise aren't required to perform this sort of index-to-string translation.

Could this perhaps be a case where the name of the case should be encoded for refines? Or othrewise could the text syntax use some sort of $id to reflect that index resolution is happening on it?

[lukewagner]

Great point! I agree that is a discrepancy that should be fixed. On first thought, I'd lean toward keeping the binary format as-is and going the $id route in the text format:

(variant (case <id>? <name> <valtype> (refines <id>)?)+)

In the wit format, I think it'd be fine to just use the case's id (no label/string distinction), which is what the human would want to read/write. Sound good?

[alexcrichton]

Seems reasonable to me, although @peterhuene given your thoughts here you may also wish to weigh in.

[peterhuene]

I'm onboard with this approach; what I didn't want us to do is have (case <id> <valtype> (refines <id>)?), as the wast component model implementation had this earlier on in a few places where identifiers were being used for what should be arbitrary strings in the binary encoding, putting restrictions on what the names could be.

[peterhuene]

Question: I assume the lexicographical scope of these identifiers is the variant definition? Thus the identifiers must be unique within a variant definition and cannot be resolved from outside of the definition.

[lukewagner]

Yes and yes. And then getting into the super-fine details: it seems like we could get away with only allowing references to preceding case indices (thereby avoiding cycles and the otherwise need for cycle detection).

[peterhuene]

Great, thanks. I've preemptively implemented it as described in wast.

[lukewagner]

Resolved by #40