Limit type inference to bottom up, give the literals a type.

[ghost]

With the choice of a post-order encoding, bottom-up typing is obvious and could be used in the binary encoding too, see WebAssembly#620

The literal constants do not have a type specifier and for bottom-up typing they need a type. There is not always a top-down type either for example (drop (i64.const 1)) is ambiguous in the text format. Could use 1L for i64 and 1F0 or 1D0 etc for the floats.

[qwertie]

As I mentioned already in the comments on my PR. I don't mind type inference - it's handy and not hard to implement (and remember that we don't have the efficiency concerns here that we have in the binary format) - but we should be able to specify the type concisely. It goes without saying that the type inferred for a dropped value will have to be specified at some point, but it hardly matters. I'd say treat 1234 as an i32 until proven otherwise.

[ghost]

@qwertie If there were some bottom up type specialization in the binary encoding then it would not be necessary to specify the type in the text format, and not even possible. The redundant information just causes trouble and adds complexity. Bottom up type specialization could be efficient when decoding the post-order encoding, but not so top-down specialization.

[sunfishcode]

This issue has surfaced in our implementation too.

Since we have type inference for infix operators, my thought was that it'd be nice to have type inference for literals too. drop (if wasm adds that) or unused values in block-like constructs (if it doesn't), seems to be the only context where the type cannot be inferred, and that's a very uncommon case because it's trivially dead code. One idea I'm considering is an optional suffix that would be required only in otherwise ambiguous cases.

[ghost]

The wasm binary encoding could combine i32.add i64.add etc into just an add operator, and given the encoding it could use bottom up types to specialize the operator and it could do so relatively efficiently, but not so for top-down typing. Perhaps just a personal opinion, but I think it might be clearer if the text format typing paralleled the typing used by the binary encoding, and thus did not use top-down typing.