Conversation
Signed-off-by: Brian Hardock <brian.hardock@fermyon.com>
lukewagner
left a comment
lukewagner
left a comment
There was a problem hiding this comment.
Thanks so much for working on this! I can't wait to start using this in official tooling and docs. Just a few nits and small suggestions:
| Alternatively, a WIT file can contain a single unnamed | ||
| [`component`][components-wit] definition, which provides a lightweight way to | ||
| define the imports and exports of a component without requiring a `package` | ||
| declaration, namespace, package name, or world name. |
There was a problem hiding this comment.
| Alternatively, a WIT file can contain a single unnamed | |
| [`component`][components-wit] definition, which provides a lightweight way to | |
| define the imports and exports of a component without requiring a `package` | |
| declaration, namespace, package name, or world name. | |
| Alternatively, a WIT file can contain a single unnamed | |
| [`component`][components-wit] definition, which provides a lightweight way to | |
| define the imports and exports of a component without requiring a `package` | |
| declaration, namespace, package name, or world name. In such cases, the WIT | |
| file cannot be built into a distributable WIT package but is instead fed directly into | |
| the producer toolchain building a specific component. |
| defining the imports and exports of a single component and don't intend to | ||
| publish the WIT as a reusable package. | ||
|
|
||
| A `component` definition is an unnamed world: it has `import` and `export` |
There was a problem hiding this comment.
| A `component` definition is an unnamed world: it has `import` and `export` | |
| A `component` definition is like a `world` definition: it has `import` and `export` |
| * A WIT file must contain **either** a `package` declaration (with optional | ||
| `world` and `interface` definitions) **or** a single `component` definition, | ||
| but **not both**. This invariant is enforced by the parser. |
There was a problem hiding this comment.
Question: could there be multiple WIT files (fed into wasm-tools just like today), as long as none of the files contain a package declaration if any of the files contains a component definition?
| automatically select the unnamed component when the WIT file contains a | ||
| `component` definition, without requiring the user to specify a world name. | ||
|
|
||
| ### Motivation |
There was a problem hiding this comment.
Could we perhaps reframe this section from "Motivation" to "Guidance for when to use a component vs. world definition"?
|
|
||
| package-file ::= (package-decl ';')? (package-items | nested-package-definition)* | ||
|
|
||
| component-file ::= (toplevel-use-item | nested-package-definition)* component-item |
There was a problem hiding this comment.
Could we perhaps allow (at most one, enforced by validation, not grammar) component-item anywhere in the file (not just at the end)? This is nice when folks want to write things in a top-down definition order, and generally allowed since WIT definitions are order-independent.
| A `component` definition is an unnamed world that can appear as the sole | ||
| top-level construct in a WIT file (see [WIT Components][components-wit]). Its | ||
| body is identical to a `world` body. | ||
|
|
There was a problem hiding this comment.
| A `component` definition is an unnamed world that can appear as the sole | |
| top-level construct in a WIT file (see [WIT Components][components-wit]). Its | |
| body is identical to a `world` body. | |
| A `component` definition is like a `world` definition without a name (see | |
| [WIT Components][components-wit]). Its body is identical to a `world` body. | |
| body is identical to a `world` body. | ||
|
|
||
| ```ebnf | ||
| component-item ::= 'component' '{' world-items* '}' |
There was a problem hiding this comment.
| component-item ::= 'component' '{' world-items* '}' | |
| component-item ::= 'component' '{' world-definition* '}' |
2 participants
This PR proposes changes to WIT.md to address #598.
First attempt, mostly trying to capture what I distilled from the discussion (and some opinion sprinkled in the rules where ambiguity around wit directories arose while prototyping).
I'm working on a prototype for
wasm-toolsandwit-bindgen(rust only to start).