Widening the WASM interface

[iamrecursion]

Currently the WASM interface is very limited, which is great for building a REPL but makes it harder to build more interactive tools as the interface is string-in, string-out. How much willingness would there be to accept patches that provide more exposure of the internals through WASM to enable things like better diagnostics, custom module loading, errors as data, and so on?

I'm working on building a Numbat integration for Obsidian, and right now I've got a lot of hacks in the plugin code to do things that Numbat knows and can provide, but does not. I wanted to assess willingness to accept such contributions should I make them, or whether it would be a "expose some things I need and build my own interface crate" or "shallow fork" situation.

Version 1.0.0 of the plugin can be found here, and relies a lot on the hacks.

[sharkdp]

I'm working on building a Numbat integration for Obsidian

That's awesome!

Currently the WASM interface is very limited, which is great for building a REPL but makes it harder to build more interactive tools as the interface is string-in, string-out. How much willingness would there be to accept patches that provide more exposure of the internals through WASM to enable things like better diagnostics, custom module loading, errors as data, and so on?

I'd be okay with accepting small incremental changes in this direction. Maybe there are some opportunities to make the web version of Numbat better along the way (we should definitely use the web version of Numbat as a client of that new interface, instead of designing a second interface).

[iamrecursion]

Awesome to hear! The top changes I'd be eyeing at the moment are as follows (in no particular order):

• Some kind of evaluation budget/yield point system for execution. I recently swapped to executing in a web worker in the plugin to prevent runaway executions, but it would be nice to be able to support something similar in the single-threaded mode as well.
• Exposing the ability to reset the context to a historical point by deleting bindings from it.
• Exposing Context::interpret with a typed interface.
• Exposing more queries about the current context that I can use for inlay hints, type info, etc. Similarly more queries about the completion vocabulary.

For a summary of the kinds of things I'm having to hack around at the moment this doc is decent, but no obligation to look or anything!

Do you have any opinions on which are sensible to start with, or shall I just pick something relatively low interface-impact and run with it to start with?

[sharkdp]

Some kind of evaluation budget/yield point system for execution. I recently swapped to executing in a web worker in the plugin to prevent runaway executions, but it would be nice to be able to support something similar in the single-threaded mode as well.

Sounds interesting, but goes beyond a new API, right? We would need to support that in the VM.

Exposing the ability to reset the context to a historical point by deleting bindings from it.

Hm, interesting. I wonder if this should be implemented in clients instead? Or is it too expensive to keep multiple Numbat Context snapshot in memory?

Exposing Context::interpret with a typed interface.

👍

Exposing more queries about the current context that I can use for inlay hints, type info, etc. Similarly more queries about the completion vocabulary.

👍

Do you have any opinions on which are sensible to start with, or shall I just pick something relatively low interface-impact and run with it to start with?

Starting with "Exposing Context::interpret with a typed interface" sounds like a good idea to me?