Allow wasm_module_t be created not from wasm bytecode.

[yurydelendik]

(generalized from #122)

The wasm_module_t is used as a container for metadata: set of definitions for its functions, memory, etc. It will be nice to allow non-wasm module to be used in wasm-c-api environment.

The WASI usage is a good example: a host might select to mix different implementations of wasm-c-api and wasi (from different libraries). It will be nice to provide a mechanism to emit a module, that describes desired interface, and controls its instantiation via wasm_instance_new. The alternative is: to construct a wasm_instance_t at the same time as a wasm_module_t. Neither is possible at this moment.

[rossberg]

I'm not sure I understand the proposal. What would such a module be? AFAICT, there is no corresponding mechanism in engines. What could you do with it other than trivially instantiating it?

I could imagine an API for constructing an instance directly from func/global/table/memory objects, but why do you need a corresponding module?

[yurydelendik]

What could you do with it other than trivially instantiating it?

I could imagine an API for constructing an instance directly from func/global/table/memory objects

Mostly for dependencies resolutions and instantiation stage, at the host side. At the moment, the new layer of abstractions has to be created to hold on func/global/etc types, and then on their corresponding instances.

What would such a module be?

A module would be just a collection of import/export types.

[rossberg]

Hm, I'm still rather fuzzy on what you have in mind. Can you sketch the signature of the constructor function for creating such a "host" module?

[yurydelendik]

Can you sketch the signature of the constructor function for creating such a "host" module?

(I'm experimenting with that at wasmtime-wasi, see wasmtime_wasi_module_new) Based on my experimentation with wasi, the following signature will be needed:

own wasm_module_t* wasm_module_create_raw(
  wasm_store_t*, const wasm_importtype_vec_t*, const wasm_exporttype_vec_t*,
  wasm_instance_new_callback_t callback
);
// where wasm_instance_new_callback_t is
typedef own wasm_instance_data_t* (*wasm_instance_new_callback_t)(
  wasm_store_t*, const wasm_module_t*, const wasm_extern_t* const imports[],
  own wasm_trap_t**
);

[rossberg]

Thanks, I see. This seems plausible, but it strikes me as something that may easily and more naturally be modelled as a separate layer. Is there a reason why it would need to be lowered into the core API? The purpose of this API is to provide a direct abstraction of the functionality encapsulated by a Wasm engine. The functionality you describe could be implemented in an engine-independent fashion on top of that.

[yurydelendik]

Is there a reason why it would need to be lowered into the core API?

The main reason is to avoid modeling new abstraction layer.

[sbc100]

It seems to me that any WASI implementation is going have to have it own higher level method for doing dependency resolution. I'm not sure that allowing WASI interface implementations to be modeled as actual wasm module (when they are not) is something that the C API should allow or encourage.

I would also really like see a world in which an wast host can choose from a variety of wasm-c-api implementations, but I'm not sure I see how this would help with that.