FYI, I trad-coded a `.wit` parser in Kotlin. It’s ...

# webassembly

[jessewilson]

FYI, I trad-coded a .wit parser in Kotlin. It’s about 2,000 lines of code and it successfully decodes all the WASI .wit files. I’m intending to use this to built a host-side component model support, to complement Kotlin 2.4’s guest-side component model support.
https://github.com/wasmcomputercompany/wasmo/tree/main/support/wit
This is not yet a standalone open source project, but if anybody wants that, I’m happy to do that work.

[curioustechizen]

TIL trad-coding.

[curioustechizen]

And TIL wasmo. Of all the ways you could have announced the project to the world, this is the one you choose? 😄

[jessewilson]

I'll do a proper announcement when it does something useful! We're not there quite yet

[bashor]

@jessewilson 👍 Thanks for sharing!
We will need something like that in the future. (cc @Jim Teichgräber)

[jessewilson]

I’ve extracted this project into a standalone GitHub here:
github.com/wasmcomputercompany/brevity

[jessewilson]

We hit a nice milestone today:
1. We declared a concatenate() in .wit ,
2. Brevity generated a commonMain interface plus lots of tricky bridging code
3. We implemented it in wasmWasiMain
4. We called it from jvmMain via Chicory.

[jessewilson]

Although that works, that’s a pretty thin spike and there’s a lot of important work to do before this is useful. For example, we don’t yet cover such types as future or tuple or even bool.

[jessewilson]

Medium-term goal is to replace Chicory with either Endive or Cranelift (via Java FFM)

[jessewilson]

I’d also like to somehow make async work, though I need to wrap my head around the semantics of that

[jessewilson]

If this is at all useful in Kotlin’s own implementation of the component model, I’d love to contribute it. When it’s ready.

[jessewilson]

Brevity is now capable of generating nice Kotlin APIs for Wasm hosts (via Chicory, for now) and guests. The generated code looks nice, like it was written by somebody who likes Kotlin.

We are working through all the test cases for encoding and decoding all of the component model data, using Rust as a reference implementation.

Our implementations are stubbed out, here's a sample declaration of Wasi P2:

https://github.com/wasmcomputercompany/brevity/blob/main/brevity-wasi-p2/src/jvmMain/kotlin/brevity/wasi/p2/RealWasiP2Host.kt

And here's our Gradle plugin that reads .wit and emits .kt for commonMain (interfaces and value types), jvmMain (host) and wasmWasiMain (guest)
https://github.com/wasmcomputercompany/brevity/blob/b24200f232344659a6a7369a6145f26c61310bdb/brevity-integration-tests/build.gradle.kts#L46

[jessewilson]

Calling between Kotlin and Java is just plain nice. Types like List, Unit, and Any compile to appropriate JVM types and there’s no ugly bridging on either end. Other JVM languages don’t have it this nice.

With Brevity we’re trying to do the same for Kotlin + WebAssembly. Today I sent out this PR to do type mapping in-the-framework so application code doesn’t have to at the boundary.

We can take WASI 0.2’s wall-clock type and generate an interface that uses Kotlin’s `Instant`:

// Generated by Brevity. Do not edit.
package wit.wasi.clocks.v0_2_0

import kotlin.time.Instant

public interface WallClock {
  public fun now(): Instant
  ...
}

(This uses a manually-registered adapter to build the Instant instance at runtime.)