Bring names in line with AST semantics sooner rather than later

[titzer]

Before we get too far along I think we need to have a referendum on the naming going on in the spec. In particular, I think the spec should follow naming conventions that have already been agreed upon in AstSemantics.md. Also, we should solve some of the outstanding issues with naming in AstSemantics.md.

In particular, the operation.type in the spec bothers me. This might come from a viewpoint where operations are parameterized over types in some way. That kind of doesn't make sense, since there are many floating point operations available that don't work on integers and vice versa. Therefore I think it's more logical to do what we were doing before and consider operations to be members of types.

E.g.

type.operation
type.operation[type]

[kg]

We really need this. I've spent a while reading over the ml-proto and I still can't figure out how to mentally map name -> ast node -> name. The way it works currently is very confusing to me.

[rossberg]

I'm fine with inverting the S-expr naming scheme in the proto. FWIW, it was inspired by good old M68k syntax, not by parameterisation.

[rossberg]

The biggest other discrepancy probably is with the zoo of conversion operators. One reason for the difference was that the naming in the AstSemantics is rather irregular, so kind of impossible to factorise in a pleasant manner. Can we perhaps do something about that?

[sunfishcode]

Could you be more specific about the irregularity you observe? The current set of names is aimed at emphasizing semantic differences among the conversions.

[rossberg]

@sunfishcode, I understand the motivation, but I'm not convinced it buys anything in a code format not targeted at humans anyway. In fact, find it rather difficult to memoize all the different names, and S-expr generators likewise will have to go through extra hoops to select them.

Conversions essentially form a 2D matrix (with a few holes; 3D if you want to count sign handling). It's unfortunate if different elements in this matrix require different naming schemes. (Or if both index dimensions are annotated in different ways, for that matter.)

[rossberg]

I'll probably have plenty of time on the plane tomorrow, will do a first round of lining up naming.

[sunfishcode]

@rossberg-chromium Humans finding it difficult to memorize all of the different names is a human-oriented concern :-). Using a single name to represent different kinds of things is an abstraction.

All compiler backends I'm familiar with (e.g. LLVM and GCC) use different opcodes to represent the different kinds of conversions, because there are significant semantic differences between them.

[lukewagner]

Are there any major discrepancies left?

[binji]

Here are the ones I noticed: do_while, forever, continue, comma, conditional, call_direct.

[sunfishcode]

do_while, forever, continue, comma, and conditional are under discussion in issues such as WebAssembly/design#223 and WebAssembly/design#299 .

The design's call_direct and the spec's call probably aren't waiting for anything though. Anyone want to state a preference?

[qwertie]

@sunfishcode call sgtm.

[sunfishcode]

I submitted WebAssembly/design#365 to rename call_direct to call.

[sunfishcode]

I think we've covered all the basic naming discrepancies between spec and design now, with the exceptions of several things which have open issues, such as those mentioned above, #65, etc.

Of course, if anyone finds any that we missed, please file a new issue!