Importing console_log should not break the WebAssembly Compoenent Model

[guest271314]

bytecodealliance/wasm-tools#2483

From what I can see, the WIT is fine and wasm-tools is doing the right thing, but the WAT being passed to watToWit does not match the naming scheme wasm-tools expects for the specified WIT interface. Specifically, wasm-tools expects an import named "console-log" from a module named "env" based on the declared name in the WIT file. Instead, it's finding an import named "console_log" from the module named "env" and doesn't know what to do with it.

WIT is intended to provide a human-readable representation of the Component Model type system, which does not cover every possible existing ABI and naming convention used in Wasm modules that exist in the wild. The expectation is that the module author (or binding generator) will have the Component Model "canonical" ABI and naming convention in mind when creating the application, which may require source code modifications.

I do recall there was a plan to eventually support other (i.e. "non-canonical") ABIs and/or naming conventions in the Component Model, but I'm not aware of any existing support for that in the specification or in wasm-tools.

[lukewagner]

IIUC, this use case could be addressed by this @external-id idea that we've discussed in various places and might get rolled into #613.

So as background, the grammar of name strings in WIT and component imports/exports is intentionally super-restrictive (see label in this section for the lexical grammar) so that names can be idiomatically mapped to identifiers by automated bindgen in a variety of source languages (each of which has its own capitalization schemes and syntactic limitations). But of course this is a problem if you want to use a WIT name string as a key into some preexisting host namespace (such as the JS API WebAssembly.instantiate()'s importObject, in your example) where the names are pre-defined and outside the limited syntax of label. And this is the problem potentially addressed by an @external-id("string") annotation on imports/exports: it's an arbitrary Unicode "string" associated with an import or export name that can be used, instead of the limited kebab-case string, when externally keying into preexisting, externally-defined namespaces.

So then concretely, I think the WIT you'd generate in your example would be:

world quic-wasm-world {
  import env: interface {
    @external-id("console_log")
    console-log: func(argv: string);
    ...

and then this could generate WAT like:

(component
  (import "env" (instance
    (export "console-log" (external-id "console_log") (func (param "argv" string)))
    ...

so that the external-id is a part of the AST of imports/exports (not in a custom section). And then the JS API (and Jco) could be defined to use external-ids, when present, as the import string, so it'd use console_log, not console-log. And then when doing guest bindgen (for the code running inside the component) from quic-wasm-world, we'd still have a well-behaved label from which to generate identifiers in various source languages, so if you're in a camel-case language, you'd get consoleLog or ConsoleLog.

This might seem like overkill for _-vs--, but it also covers all the other Unicode characters that are allowed in core wasm import/export names (as well as JS module specifiers), so it seems preferable to extending label in a one-off manner.

[guest271314]

Yeah, I'm not seeing where in the linked specification function names like a_b are valid WIT, yet not valid WebAssembly Component Model - explicitly. I did not expect WAT representation to be valid WIT, yet wasm-tools says error!

Of all programming paradigms, I would think WebAssembly world would not create a sub-design that is not compatible with the original design. "The universal executable". That is, the same code should be portable, everywhere; starting with WebAssembly Core Modules to WebAssembly Component Model, by any means.

Further, I could not find a WAT to WIT tool in the WebAssembly world. I got Google Demini to spit one out. Turns out, it's valid WIT from WAT - but not valid WebAssembly Component Model name?

Why even bother with a new programming syntax? Just use JSON, which can be binary data, too. I think of the Cap N Proto of Cloadflare's Workerd. It's a whole 'nother language!

With that said, I would suggest developing the whole flow chart:

• WAT => WIT => Component Model

In house.

To and fro WebAssembly Core Module probably should be a core design goal. As much as the Component Model is being worked on and such, and as much as there is already WebAssembly deployed in the wild, it might be useful to invite existing WebAssembly Core Module world into Component Model world, in a single command, and back, in a single command.

To me, I don't really care what the implementation details are, as long as I can port to and fro, across programming design paradigms - within the same programming language.

So if you do the

and then this could generate WAT like:

(component
  (import "env" (instance
    (export "console-log" (external-id "console_log") (func (param "argv" string)))
    ...

you should have a program that does that from WAT, and gets the WAT back to Core Module.

[guest271314]

@lukewagner

Hmm. This?

The label production used inside plainname as well as the labels of record and variant types are required to have kebab case.

That "are required to have" is explicit as "MUST". Avoids ambiguity; or just thinking, wait, I know the WebAssembly folks didn't just say I and "required" to name my functions a certain way!

[lukewagner]

Yep, that's right. It also falls out from just the raw grammar rules, but "must" is a good change to be clear about these things.