bytecodealliance
Text Format (%.wat) generator
The wit format is neat in that it gives hints like string to make better language bindings. However, in the process, it can be confusing what the actual imports will be. This is especially confusing as there are a couple string-based proposals to the spec. It would be nice to be able to generate%.wat instead and use that as the gold copy (for those who prefer seeing the raw wasm signatures). If we had this feature, it would be less scary to use the higher level types, which are becoming more interesting.
Do you have an example of what you'd like to see generated? I would naively interpret this as:
$ cat foo.wit
foo: func()
$ wit-bindgen guest wat --import foo.wit
(module
(import "foo" "foo" (func))
)
but I'm not sure if that's what you are thinking of? Or are you wondering to get the full component representation instead?
yes! for starters non-componentized is great. meanwhile I was thinking to emit c and then wasm2wat the result ;)
I think this is very important especially as modeling is fluid here. For example, it isn't intuitive that 64bit flag would be two fields, especially as wasm supports 64 bit and when used as a parameter two places is clunky. We need a way to know that decisions in markup will result in consistent wasm signatures, even if not enforced via wat. otherwise, we'll need another markup that can be trusted to not drift. as you can imagine, some may think of this as a spec document and if the representation changes without someone knowing, it fails at its primary purpose.
Do you have an example of what you'd like to see generated? I would naively interpret this as:
$ cat foo.wit foo: func() $ wit-bindgen guest wat --import foo.wit (module (import "foo" "foo" (func)) )but I'm not sure if that's what you are thinking of? Or are you wondering to get the full component representation instead?
@alexcrichton That would be incredibly useful (especially if it spit out some wat I could link with other components written in rust, using wasmtime Linker). If one were to try to implement that, where would you suggest they start digging around? Any tips?
This is actually already implemented here so the implementation here would be mostly to expose that in a package somewhere.