3 ms·

> They can't really be done as libraries. It's definitely the case that you can't implement a string type in WASM and have it interoperate with JavaScript stri

> They can't really be done as libraries. It's definitely the case that you can't implement a string type in WASM and have it interoperate with JavaScript strings. But there is no reason that JavaScript strings can't be a "special" kind of import that provides functionality implemented by the engine. In other words, #include <wasm/wtf16string.h> could provide an API for the built-in JavaScript string, much like #include <ruby.h> provides access to the native Ruby string in Ruby extensions. I believe this is how the counter-proposal works: https://github.com/WebAssembly/js-string-builtins/blob/main/proposals/js-string-builtins/Overview.md https://github.com/WebAssembly/js-string-builtins/blob/main/... For engines that do not have a built-in JavaScript-like string type, the wasm/wtf16string.h library could be implemented in WASM as a polyfill. In that case, there is no native string to interoperate with, so no disadvantage to implementing directly in WASM (except perhaps a bit of speed penalty).

chubot 3y ago
What I'm reading there is that it's less ambitious -- it would only work for languages that have JavaScript string semantics. Some languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent JavaScript primitive for their implementation I believe Java fits that bill (it's UTF-16, at least). So if you were writing a JVM to work on WASM, then you could possibly just import the JS string and use it, and get zero-copy inter-op. --- But what the Wingo article is saying is they want something even more ambitious: have a working Scheme or Python or Lua implementation with zero-copy JS inter-op. If they can paper over the bytes vs. UTF-16 vs. code points API issue, making a single string type that's not biased toward one or the other, I think it's a step in the right direction. (The aside about decoupling JS itself from UTF-16 string APIs is pretty intriguing too!) But it's still not obvious to me that even this gets you all the way there. For example, Python interns some strings, and Lua apparently interns ALL strings, and they both have hash codes in the string object, and expose it to users. (Even changes to the hash function may break some programs) Unique object IDs in many languages are another issue -- the JVM apparently uses space for them in the header of every object. So you still may have more compromises about how to implement the WASM string, that produces winners and losers. The only way to know how the compromises pan out is to try, and I'm glad people are doing that. --- So anyway, I'm not very close to WASM, but I do see a pretty clear difference between the proposals. I think it depends on what the goals are -- is "running Python or Scheme with zero-copy JS string interop" a goal? I guess people want to manipulate the DOM directly from Scheme or Python, which seems reasonable. If you have to copy all the strings, that will be a huge drag. DOM operations are already hugely expensive and have tons of objects. It seems like the proposal you linked doesn't address that issue.

chubot 3y ago

What I'm reading there is that it's less ambitious -- it would only work for languages that have JavaScript string semantics. Some languages targeting WebAssembly may have compatible primitives and would benefit from being able to use the equivalent JavaScript primitive for their implementation I believe Java fits that bill (it's UTF-16, at least). So if you were writing a JVM to work on WASM, then you could possibly just import the JS string and use it, and get zero-copy inter-op. --- But what the Wingo article is saying is they want something even more ambitious: have a working Scheme or Python or Lua implementation with zero-copy JS inter-op. If they can paper over the bytes vs. UTF-16 vs. code points API issue, making a single string type that's not biased toward one or the other, I think it's a step in the right direction. (The aside about decoupling JS itself from UTF-16 string APIs is pretty intriguing too!) But it's still not obvious to me that even this gets you all the way there. For example, Python interns some strings, and Lua apparently interns ALL strings, and they both have hash codes in the string object, and expose it to users. (Even changes to the hash function may break some programs) Unique object IDs in many languages are another issue -- the JVM apparently uses space for them in the header of every object. So you still may have more compromises about how to implement the WASM string, that produces winners and losers. The only way to know how the compromises pan out is to try, and I'm glad people are doing that. --- So anyway, I'm not very close to WASM, but I do see a pretty clear difference between the proposals. I think it depends on what the goals are -- is "running Python or Scheme with zero-copy JS string interop" a goal? I guess people want to manipulate the DOM directly from Scheme or Python, which seems reasonable. If you have to copy all the strings, that will be a huge drag. DOM operations are already hugely expensive and have tons of objects. It seems like the proposal you linked doesn't address that issue.