Separate WITX from WASI

[syrusakbary]

Today I saw a PR that was created, reviewed and merged in a few hours, with interaction just from people working in Fastly, but no one outside.

This is fine per se, but it made me realize that perhaps the WASI repo itself should just contain the specification and not any implementation details, since most of the VM implementors are watching the repo just for changes in the specification.

Separating implementation from specification is a common practice that is also followed by other projects.
For example, GraphQL has a specification repo (that includes no code whatsoever) and a reference implementation repo.

Perhaps will be a good idea to move WITX outside of the WASI spec repo since it's an implementation tool that depends only (one way) on the specification.

[pchickey]

Your characterization of the witx tool's role is incorrect. The specification depends on the witx tool for validation (making sure .witx documents are properly defined and internally consistent). Additionally, the canonical location of each datatype and function documentation are in doc comments in the .witx documents, and the witx tool renders those to markdown to improve human consumption. Both of these are checked as part of the CI process.

Downstream tools that generate implementations from witx files live in other repositories, and can depend on the witx crate for parsing, or not.

[sbc100]

I guess it might make sense if there were non-WASI uses for witx out there? Then WASI would pull in witx as sub-module/crate?

Do such users exist? Its hard to imagine that they do since witx itself was designed specifically for WASI. It seems like unless there are good reasons not to, managing the witx library code alongside the spec has major productivity advantages (just like the WebAssembly spec and reference interpreter are maintained in single repo).

[syrusakbary]

@pchickey Thanks for clarifying. I understand WITX is a tool on top of WASI, and not a WASI implementation.
What I meant to say is that witx (the crate) is an implementation tool used in WASI (the specification).

I always believed separating specification from any implementation code (regardless of tooling implementation or spec implementation) was a good practice, but perhaps my thoughts are not shared 🤷‍♂️.

Do you think it would make sense to separate the witx crate to its own repo, and reuse the binary when testing the WASI spec? That way witx could also be reused outside of WASI

Edit: @sbc100. I read your reply a bit after posting! I'm happy with either path tbh, I personally think the tradeoff of separating spec & tooling is useful in any case, but it's a tradeoff nonetheless :)

[pchickey]

The WebAssembly spec repository has always contained the reference interpreter, and the witx crate is an analogous tool for WASI. And, like the reference interpreter evolves alongside the WebAssembly spec, the witx crate evolves alongside the WASI spec.

In the past we have evolved the spec and crate in lock-step, e.g. in #220 when we introduced new concepts, like tagged unions, to the witx language and the WASI spec simultaneously. The spec and the witx language are still evolving and big changes to use wasm proposals like module linking and interface types are on the horizon, so we will have to make more of these sort of changes in the future. Adding repository-level indirection would make these changes harder to develop and harder for consumers of the spec to follow and understand.

We publish the witx crate on crates.io for users who wish to consume it outside of the context of WASI.

[syrusakbary]

Seems reasonable! Closing issue