Allow quoted identifiers

[rossberg]

Address #21.

Allow arbitrary non-empty names (well-formed unicode string literals) as identifiers.

Extend spec, interpreter, and test suite.

Note: This PR does not per se remove the explicit @name annotations from the proposal, because they are not equivalent: they express the actual presence of a corresponding custom section, whereas the use of symbolic names doesn't, even though they can be utilised by a tool to construct such a custom section (as before). Also, annotations are more expressive, e.g., can provide alternative names to the same binder, i.e., quoted identifiers are not sufficient to convert all forms of name section into text.

[tlively]

The name annotation might technically be more expressive, but is there any demand for it? We shouldn't spec something that nobody implements or uses.

[rossberg]

Well, the idea underlying this proposal is that every custom section should have a text equivalent.

[tlively]

Why disallow the empty name? $"" seems like it should be a valid identifier.

[tlively]

The rendering of \text{@"..."} is pretty ugly. Can we use \ldots in there to make it prettier?

[tlively]

Well, the idea underlying this proposal is that every custom section should have a text equivalent.

The syntax for arbitrary custom sections means that this goal is met without the @name annotation, albeit not in a very useful way. I would still like to see evidence that anyone wants to use the @name annotations. @alexcrichton, you were concerned about reduced expressivity without the @name annotations in this comment. What are you current thoughts on the usefulness of the @name annotations?

[alexcrichton]

In the abstract I do not personally have a use case for @name insofar as all practical wasm modules I've worked with all have a name section where names are unique and fit the existing identifier grammer. I've only used @name in testing/fuzzing/etc, never for a real-world module.

My comment there though was also specifically addressing the point that if the purpose of @name is to have a text format representation for any valid name section then somehow duplicate names need to be handled as well. Removing @name, which this PR is not proposing, would mean that such a name section could not be represented in the text format. I don't know if this is a big issue though. A name section which names function 10 in a module of 8 functions also can't be represented in the text format.

[rossberg]

A name section which names function 10 in a module of 8 functions also can't be represented in the text format.

I'm afraid that's apples vs potatoes: the existing spec of the name section already requires referenced indices to exist, but at the same time explicitly allows multiple names for a given index. The custom section validator implemented for the reference interpreter as part of this proposal even checks it accordingly. ;)