Easier binding of host Kotlin functions to Kotlin/Wasm running within Chasm

[Laxystem]

Chasm looks like an incredibly cool project, and the possibilities are countless.

The most natural extension to WASI support would be running containerized Kotlin/WasmWasi using Chasm, with access to specific packages from the host, similarly to KotlinScript (.kts).

Therefore, my suggestion—allow to simply reference functions to expose them to the Chasm container, for example:

fun Foo.myHostApi(): Bar

instance.expose(Foo::myHostApi)

Or even entire packages:

instance.exposePackage("com.example.gameEngine")

My optimal API for this would be to have some kind of @ChasmExposed annotation:

instance.exposeAnnotated<ChasmExposed>()

Reflection data (that is not available in runtime due to multiplatform limitations) for the latter two could be made up for using some kind of compiler plugin similarly to KotlinX Serialization.

But of course, the initial request is to simply be able to expose functions automagically.

The ultimate extension to this would be to somehow support (an improved version of) the KotlinScript API, but this is a separate issue entirely that'll likely need to be developed in collaboration with the Kotlin Foundation.

[Laxystem]

I'll expend on my use case: the ability to have pure, scripty Kotlin, without any form of access to implementation details or the running OS.

KotlinScript lacks in this, as it can still bypass @RequiresOptIn APIs, and it was very hard if not impossible to containerize it.

For my game engine, I'm looking for a way to simply have, say:

// example.system.kts

for ((entity, gravity) in entities[Gravity]) entity[Position] += gravity.modifier * deltaTime

Compile it into Kotlin/Wasm, and run it anywhere, without any fear of platform compatibility, security, anything—just containerized logic that only has access to what I give it. KotlinScript, but good, that is. So here I am, suggesting the first step towards it: adding Kotlin functions to the container without unnecessary boilerplate.

Then, support for types and later KotlinScript syntax, and walla! We have containerized Kotlin.

[CharlieTap]

Hey @Laxystem

This is something thats planned, a while back I added a moduleInfo api which describes a wasm module in terms of its imports and exports alongside all the necessary type information. The idea is that you can easily use this information inside of a gradle plugin to generate a kotlin interface and implementation which hides chasm and its low level api. This is the end goal of how I want people to interact with chasm because it would make end users less dependent on chasms abi, and thus could innovate without worrying about breaking peoples programs.

TLDR its high on the list but not just yet, I'm open to prs and also the api to make this happen is public so you could even have a distinct library that just wraps chasm if you wanted