Fix some other minor discrepancies between Explainer.md/Binary.md/CanonicalABI.md

Author: lukewagner

design/mvp/Binary.md

@@ -34,7 +34,7 @@ section   ::=    section_0(<core:custom>)         => ϵ
             | a*:section_6(vec(<alias>))          => a*
             | t*:section_7(vec(<type>))           => t*
             | c*:section_8(vec(<canon>))          => c*
-            | s: section_9(<start>)               => [s]
+            | s: section_9(<start>)               => [s] 🪙
             | i*:section_10(vec(<import>))        => i*
             | e*:section_11(vec(<export>))        => e*
             | v*:section_12(vec(<value>))         => v* 🪙
@@ -87,7 +87,7 @@ sort                ::= 0x00 cs:<core:sort>                                => co
                       | 0x03                                               => type
                       | 0x04                                               => component
                       | 0x05                                               => instance
-inlineexport        ::= n:<exportname> si:<sortidx>                        => (export n si)
+inlineexport        ::= n:<exportname'> si:<sortidx>                       => (export n si)
 ```
 Notes:
 * Reused Core binary rules: [`core:name`], (variable-length encoded) [`core:u32`]
@@ -301,22 +301,24 @@ canon    ::= 0x00 0x00 f:<core:funcidx> opts:<opts> ft:<typeidx> => (canon lift
            | 0x09 rs:<resultlist> opts:<opts>                    => (canon task.return rs opts (core func)) 🔀
            | 0x05                                                => (canon task.cancel (core func)) 🔀
            | 0x0a 0x7f i:<u32>                                   => (canon context.get i32 i (core func)) 🔀
+           | 0x0a 0x7e i:<u32>                                   => (canon context.get i64 i (core func)) 🔀🐘
            | 0x0b 0x7f i:<u32>                                   => (canon context.set i32 i (core func)) 🔀
+           | 0x0b 0x7e i:<u32>                                   => (canon context.set i64 i (core func)) 🔀🐘
            | 0x0c cancel?:<cancel?>                              => (canon thread.yield cancel? (core func)) 🔀
            | 0x06 async?:<async?>                                => (canon subtask.cancel async? (core func)) 🔀
            | 0x0d                                                => (canon subtask.drop (core func)) 🔀
            | 0x0e t:<typeidx>                                    => (canon stream.new t (core func)) 🔀
            | 0x0f t:<typeidx> opts:<opts>                        => (canon stream.read t opts (core func)) 🔀
            | 0x10 t:<typeidx> opts:<opts>                        => (canon stream.write t opts (core func)) 🔀
-           | 0x11 t:<typeidx> async?:<async?>                    => (canon stream.cancel-read async? (core func)) 🔀
-           | 0x12 t:<typeidx> async?:<async?>                    => (canon stream.cancel-write async? (core func)) 🔀
+           | 0x11 t:<typeidx> async?:<async?>                    => (canon stream.cancel-read t async? (core func)) 🔀
+           | 0x12 t:<typeidx> async?:<async?>                    => (canon stream.cancel-write t async? (core func)) 🔀
            | 0x13 t:<typeidx>                                    => (canon stream.drop-readable t (core func)) 🔀
            | 0x14 t:<typeidx>                                    => (canon stream.drop-writable t (core func)) 🔀
            | 0x15 t:<typeidx>                                    => (canon future.new t (core func)) 🔀
            | 0x16 t:<typeidx> opts:<opts>                        => (canon future.read t opts (core func)) 🔀
            | 0x17 t:<typeidx> opts:<opts>                        => (canon future.write t opts (core func)) 🔀
-           | 0x18 t:<typeidx> async?:<async?>                    => (canon future.cancel-read async? (core func)) 🔀
-           | 0x19 t:<typeidx> async?:<async?>                    => (canon future.cancel-write async? (core func)) 🔀
+           | 0x18 t:<typeidx> async?:<async?>                    => (canon future.cancel-read t async? (core func)) 🔀
+           | 0x19 t:<typeidx> async?:<async?>                    => (canon future.cancel-write t async? (core func)) 🔀
            | 0x1a t:<typeidx>                                    => (canon future.drop-readable t (core func)) 🔀
            | 0x1b t:<typeidx>                                    => (canon future.drop-writable t (core func)) 🔀
            | 0x1c opts:<opts>                                    => (canon error-context.new opts (core func)) 📝
@@ -339,7 +341,7 @@ canon    ::= 0x00 0x00 f:<core:funcidx> opts:<opts> ft:<typeidx> => (canon lift
 async?   ::= 0x00                                                =>
            | 0x01                                                => async
 cancel?  ::= 0x00                                                =>
-           | 0x01                                                => cancellable 🚟
+           | 0x01                                                => cancellable
 sh?      ::= 0x00                                                =>
            | 0x01                                                => shared 🧵②
 opts     ::= opt*:vec(<canonopt>)                                => opt*

design/mvp/CanonicalABI.md

@@ -898,7 +898,7 @@ the closure fields directly in the component instance table.
 A waitable can belong to at most one "waitable set" (defined next) which is
 referred to by the `wset` field. A `Waitable`'s `pending_event` is delivered
 (via `get_pending_event`) when core wasm code waits on its waitable set (via
-`task.wait` or, when using `callback`, by returning to the event loop).
+`waitable-set.wait` or, when using `callback`, by returning to the event loop).
 ```python
 class Waitable:
   pending_event: Optional[Callable[[], EventTuple]]
@@ -2384,10 +2384,10 @@ def store_int(cx, v, ptr, nbytes, signed = False):
 ```
 
 Floats are stored directly into memory, with the sign and payload bits of NaN
-values modified non-deterministically. This reflects the practical reality that
+values modified nondeterministically. This reflects the practical reality that
 different languages, protocols and CPUs have different effects on NaNs.
 
-Although this non-determinism is expressed in the Python code below as
+Although this nondeterminism is expressed in the Python code below as
 generating a "random" NaN bit-pattern, native implementations do not need to
 use the same "random" algorithm, or even any random algorithm at all. Hosts
 may instead chose to canonicalize to an arbitrary fixed NaN value, or even to
@@ -4513,7 +4513,7 @@ For canonical definitions:
 (canon future.drop-writable $future_t (core func $f))
 ```
 validation specifies:
-* `$f` is given type `(func (param i32 i32))`
+* `$f` is given type `(func (param i32))`
 * `$stream_t`/`$future_t` must be a type of the form `(stream $t?)`/`(future $t?)`
 
 Calling `$f` removes the readable or writable end of the stream or future at
@@ -4767,7 +4767,7 @@ validation specifies:
 * `memory` must be present
 
 Calling `$f` calls the following function which uses the `$opts` immediate to
-(non-deterministically) lift the debug message, create a new `ErrorContext`
+(nondeterministically) lift the debug message, create a new `ErrorContext`
 value, store it in the current component instance's `handles` table and returns
 its index.
 ```python
@@ -4789,7 +4789,7 @@ def canon_error_context_new(opts, thread, ptr, tagged_code_units):
 Supporting the requirement (introduced in the
 [explainer](Explainer.md#error-context-type)) that wasm code does not depend on
 the contents of `error-context` values for behavioral correctness, the debug
-message is completely discarded non-deterministically or, in the deterministic
+message is completely discarded nondeterministically or, in the deterministic
 profile, always. Importantly (for performance), when the debug message is
 discarded, it is not even lifted and thus the O(N) well-formedness conditions
 are not checked. (Note that `host_defined_transformation` is not defined by the
@@ -4812,7 +4812,7 @@ validation specifies:
 
 Calling `$f` calls the following function which uses the `$opts` immediate to
 lowers the `ErrorContext`'s debug message. While *producing* an `error-context`
-value may non-deterministically discard or transform the debug message, a
+value may nondeterministically discard or transform the debug message, a
 single `error-context` value must return the same debug message from
 `error.debug-message` over time.
 ```python

design/mvp/Concurrency.md

@@ -110,7 +110,7 @@ to be rewritten to use source-language concurrency mechanisms (like callbacks,
 `main()` and calls to `read()`, `write()` and `select()` can run without change
 in the Preview 3 `wasi:cli/command` world, which exports `run: async func() ->
 result`. Thus, `async` in WIT does not require the same kind of transitive
-source-code changes as source-level `async` in langauges like C#, Python, JS,
+source-code changes as source-level `async` in languages like C#, Python, JS,
 Rust and Dart.
 
 Because `async` exports impose little to no requirements on the guest
@@ -379,10 +379,10 @@ the following 3 thread built-ins. Once the thread is resumed, the thread can
 learn its own index by calling the [`thread.index`] built-in.
 
 A suspended thread (identified by thread-table index) can be resumed at some
-non-deterministic point in future via the [`thread.resume-later`] built-in. In
+nondeterministic point in future via the [`thread.resume-later`] built-in. In
 contrast, the [`thread.yield-to`] built-in switches execution to the given
 thread immediately, leaving the *calling* thread to be resumed at some
-non-deterministic point in the future. Lastly, the [`thread.switch-to`]
+nondeterministic point in the future. Lastly, the [`thread.switch-to`]
 built-in switches execution to the given thread immediately, like `yield-to`,
 but leaves the calling thread in the "suspended" state. These three functions
 can be used to resume both newly-created threads as well as threads that
@@ -658,7 +658,7 @@ component-instance-wide lock is implicitly acquired every time core wasm is
 executed. By returning to the event loop after every event (instead of once at
 the end of the task), stackless async exports release the lock between every
 event, allowing a higher degree of concurrency than synchronous exports.
-Stackfull async exports ignore the lock entirely and thus achieve the highest
+Stackful async exports ignore the lock entirely and thus achieve the highest
 degree of (cooperative) concurrency.
 
 Since non-`async` functions are not allowed to block (including due to
@@ -771,7 +771,7 @@ state and returns which state was reached. If called asynchronously, then if a
 cancellable subtask thread is resumed *and* the subtask reaches a resolved
 state before suspending itself for whatever reason `subtask.cancel` will return
 which state was reached. Otherwise, `subtask.cancel` will return a "blocked"
-sentinel value and the caller must [wait][#waitables-and-waitable-sets] via
+sentinel value and the caller must [wait](#waitables-and-waitable-sets) via
 waitable set until the subtask reaches a resolved state.
 
 The Component Model does not provide a mechanism to force prompt termination of
@@ -836,7 +836,7 @@ Despite the above, the following scenarios do behave deterministically:
   deterministically and immediately.
 * When both ends of a stream or future are owned by wasm components, the
   behavior of all read, write, cancel and drop operations is deterministic
-  (modulo any nondeterminitic execution that determines the ordering in which
+  (modulo any nondeterministic execution that determines the ordering in which
   the operations are performed).
 
 
@@ -939,7 +939,7 @@ Other example asynchronous lowered signatures:
 | `async func()`                     | `(func (result i32))` |
 | `async func() -> string`           | `(func (param $out-ptr i32) (result i32))` |
 | `async func(x: f32) -> f32`        | `(func (param $x f32) (param $out-ptr i32) (result i32))` |
-| `async func(s: string, t: string)` | `(func (param $s-ptr i32) (param $s-len i32) (result $t-ptr i32) (param $t-len i32) (result i32))` |
+| `async func(s: string, t: string)` | `(func (param $s-ptr i32) (param $s-len i32) (param $t-ptr i32) (param $t-len i32) (result i32))` |
 
 `future` and `stream` can appear anywhere in the parameter or result types. For example:
 ```wit
@@ -1174,8 +1174,8 @@ core wasm code between events, not externally-visible behavior.
     ...
   )
   (core module $Main
-    (import "libc" "mem" (memory 1))
-    (import "libc" "realloc" (func (param i32 i32 i32 i32) (result i32)))
+    (import "" "mem" (memory 1))
+    (import "" "realloc" (func (param i32 i32 i32 i32) (result i32)))
     (import "" "fetch" (func $fetch (param i32 i32 i32) (result i32)))
     (import "" "waitable-set.new" (func $new_waitable_set (result i32)))
     (import "" "waitable.join" (func $join (param i32 i32)))
@@ -1247,7 +1247,7 @@ It's also possible for `summarize` to call `task.return` called eagerly in the
 initial core `summarize` call.
 
 The `$event`, `$p1` and `$p2` parameters passed to `cb` are the same as the
-return values from `task.wait` in the previous example. The precise meaning of
+return values from `waitable-set.wait` in the previous example. The precise meaning of
 these values is defined by the Canonical ABI.
 
 
@@ -1290,7 +1290,7 @@ comes after:
 [Effect Type]: https://en.wikipedia.org/wiki/Effect_system
 [CPS Transform]: https://en.wikipedia.org/wiki/Continuation-passing_style
 [Asyncify]: https://emscripten.org/docs/porting/asyncify.html
-[Session Types]: https://en.wikipedia.org/wiki/Session_type
+[Session Type]: https://en.wikipedia.org/wiki/Session_type
 [Structured Concurrency]: https://en.wikipedia.org/wiki/Structured_concurrency
 [Unit]: https://en.wikipedia.org/wiki/Unit_type
 [FS or GS Segment Base Address]: https://docs.kernel.org/arch/x86/x86_64/fsgs.html