Calls to the embedder about spec HOT 6 CLOSED

Improvements/clarifications always welcome, but the design repo does state that the way host environments expose host-specific functionality through builtin modules (see also NonWeb.md).

Concretely, the way I was expecting this to be reflected in ml-proto:

• we'd add an imports field to Ast.module (reflecting imports in Modules.md)
• an import would roughly look like (import @importName "func_name" "module_name" (signature ...)) such that you could (call @importName ...) (like everything else, the name would be optional and an index could be used instead). check.ml would require the call's sig to match the import's sig.
• per design repo, how an import is resolved is totally up to the host environment. To reflect this in ml-proto, eval.ml would be extended so that Eval.init also took a list imported functions (assumed to match the signatures of Ast.imports) and the impl of call of an import simply called one of these functions.
• the host part of ml-proto (script.ml, which is not logically part of the spec, but part of the host environment) would then, after parsing the Ast.module from SExprs would iterate down the list of module.imports, look them up in a list of builtin functionality we'd like to expose in ml-proto (stdio, etc) to build the list of imports passed to Eval.init (or fail on unknown imports).

Thus, just like the C/C++ standard (Section 1.9 Program Execution: "The semantic descriptions in this International Standard define a parameterized nondeterministic abstract machine."), the wasm semantics would be parameterized by the host environment (the import arguments to init). When we add page_size, that value would, I expect, be another parameter to init.

To make the spec vs. reference interpreter embedding distinction clear in ml-proto, I have been thinking it'd be nice to split up the ML files into subdirs (e.g., spec (containing ast.ml, eval.ml, check.ml, types.ml, values.ml) and host (containing script.ml and SExpr parser). I think there should also be a 3rd subdir (say, given) for files that implement basic functionality that we would just take as given (and not redefine) in a real spec (viz., arithmetic.ml, after some massaging).

from spec.

On 3 September 2015 at 21:00, Luke Wagner [email protected] wrote:

Improvements/clarifications always welcome, but the design repo does state
that the way host environments expose host-specific functionality through builtin
modules
https://github.com/WebAssembly/design/blob/master/Modules.md#imports-and-exports
(see also NonWeb.md).

Concretely, the way I was expecting this to be reflected in ml-proto:

• we'd add an imports field to Ast.module (reflecting imports
  https://github.com/WebAssembly/design/blob/master/Modules.md#imports-and-exports
  in Modules.md)
• an import would roughly look like (import @importname "func_name"
  "module_name" (signature ...)) such that you could (call @importname
  ...) (like everything else, the name would be optional and an index
  could be used instead). check.ml would require the call's sig to match
  the import's sig.

This sounds reasonable to me. (Bikeshed: instead of (signature ...) I
would just reuse (param ...) and (result ...) there, to mirror func
definitions.)

• per design repo
  https://github.com/WebAssembly/design/blob/master/Modules.md#imports-and-exports,
  how an import is resolved is totally up to the host environment. To reflect
  this in ml-proto, eval.ml would be extended so that Eval.init also
  took a list imported functions (assumed to match the signatures of
  Ast.imports) and the impl of call of an import simply called one of
  these functions.

So the linking would be performed by the host? Makes sense. An alternative
model would be to pass in a module environment (a map from module names to
instances), and let Eval.init do the lookup.

• the host part of ml-proto (script.ml, which is not logically part of
  the spec, but part of the host environment) would then, after parsing the
  Ast.module from SExprs would iterate down the list of module.imports,
  look them up in a list of builtin functionality we'd like to expose in
  ml-proto (stdio, etc) to build the list of imports passed to Eval.init
  (or fail on unknown imports).

Thus, just like the C/C++ standard (Section 1.9 Program Execution: "The
semantic descriptions in this International Standard define a parameterized
nondeterministic abstract machine."), the wasm semantics would be
parameterized by the host environment (the import arguments to init).
When we add page_size, that value would, I expect, be another parameter
to init.

To make the spec vs. reference interpreter embedding distinction clear in
ml-proto, I have been thinking it'd be nice to split up the ML files into
subdirs (e.g., spec (containing ast.ml, eval.ml, check.ml, types.ml,
values.ml) and host (containing script.ml and SExpr parser). I think
there is also a 3rd subdir (say, given) for files that implement basic
functionality that we would just take as given (and not redefine) in a real
spec (viz., arithmetic.ml, after some massaging).

Makes sense. Regarding arithmetic.ml, I think it would belong into spec
as well (maybe under a better name), assuming some of the actual operator
implementations are factored out into given (in particular, Float64 and
Float32 modules like Dan is working on).

/Andreas

from spec.

So the linking would be performed by the host? Makes sense. An alternative model would be to pass > in a module environment (a map from module names to instances), and let Eval.init do the lookup.

I was also thinking along these lines. It would describe the builtin module situation well, but not the case where imports lead to dynamic fetches and, recursively, more module loading; for that it seems like you'd need some sort of "go load me this module that's not already in the map" callback which seems more complicated.

from spec.

Makes sense. Regarding arithmetic.ml, I think it would belong into spec as well (maybe under a
better name), assuming some of the actual operator implementations are factored out into given
(in particular, Float64 and Float32 modules like Dan is working on).

Agreed (that's what I was alluding to by "after some massaging" :)

from spec.

Make It So :-)

from spec.

Created #54.

from spec.