String builtins merge, passing builtinSetNames and stringConstant

[guybedford]

With the spec now merged to the latest, we can explicitly integrate with the JS String Builtins proposal, passing the builtinSetNames and stringConstant parameters to module construction.

This explicitly now passes « "js-string" » for the builtinset.

For the string constant, we had a bikeshed discussion in #118, which led to the conclusion of wasm:js/string-constants, which is specified here as well.

// cc @eqrion

[eqrion]

@guybedford Overall LGTM. I'm uncertain about the string constants import though.

I think we'd be unhappy if we were always stuck with wasm-js:strings (a verbose name) and also compact-imports is not standardized. I'd also think we'd be unhappy if we were always stuck with a short non-descriptive name like $ and compact-imports was standardized.

My understanding is that not picking a name for string constants now doesn't preclude us from picking one later? So could we continue to defer the question? I know I've not made any progress on compact-imports recently, but I do hope to pick it up soon. I think if that moves to phase 2 we'll have more clarity here.

[guybedford]

@eqrion thanks for taking a look here.

I wonder if compact imports could be framed as an optimization that would result in a single instance import like ("wasm-js:strings" "*") then being aliased off of, so that if/when we have compact imports, there would only be a single wasm-js string in the binary and that that would be something we could be ok with?

That is, can we make this decision in anticipation of compact imports that "wasm-js:strings" would work? Or would you also be concerned that there might be other factors here? And if so, what sorts of compact imports factors might alter how we'd think about this?

Would be good to discuss this further. Yes we can wait on this decision here, and still be able to decide later. But string constants are also an important piece of the string builtins story that we shouldn't delay on unnecessarily either.

[lukewagner]

Just my 2c on wasm: vs wasm-js:: although longer, wasm-js is attractive since it makes it clear from both a JS/ESM and wasm perspective that we're talking about "JS built-ins exposed to wasm" and keeps wasm: open for hypothetical pure-wasm builtins as well as non-JS builtins exposed to wasm.

[eqrion]

As mentioned on the other bug. I'm also happy with wasm:js/string/constants. I didn't think of it as a submodule before but agree that's a good way to think of it.