You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When embedding a WebAssembly module, you get to access its exports, mainly the functions that you will be calling. However, these functions only operate on very simple primitive types (integers and floating-point numbers). Richer types like strings or lists have to be represented in terms of integers and floating-point numbers, for example by the use of pointers and offsets. Those representations are oftentimes not interchangeable across languages.
The Component Model proposal aims to fix this by introducing a new abstraction for composing WebAssembly code - components. Like WebAssembly modules, components define their interface as a set of imports and exports, but unlike WebAssembly modules, only functions can be imported and exported. However, these functions have high-level type definitions and can work on rich data types.
Internally, the component is responsible for mapping these high-level data types onto the WebAssembly primitives of the underlying module. By implementing this proposal, we will improve the interoperability of GraalWasm with Java and other Graal Languages.
TL;DR
We plan to implement the WebAssembly Component Model proposal in GraalWasm.
Details
When embedding a WebAssembly module, you get to access its exports, mainly the functions that you will be calling. However, these functions only operate on very simple primitive types (integers and floating-point numbers). Richer types like strings or lists have to be represented in terms of integers and floating-point numbers, for example by the use of pointers and offsets. Those representations are oftentimes not interchangeable across languages.
The Component Model proposal aims to fix this by introducing a new abstraction for composing WebAssembly code - components. Like WebAssembly modules, components define their interface as a set of imports and exports, but unlike WebAssembly modules, only functions can be imported and exported. However, these functions have high-level type definitions and can work on rich data types.
Internally, the component is responsible for mapping these high-level data types onto the WebAssembly primitives of the underlying module. By implementing this proposal, we will improve the interoperability of GraalWasm with Java and other Graal Languages.
More details at https://component-model.bytecodealliance.org/
The text was updated successfully, but these errors were encountered: