Interpreter

[sjorn3]

Includes the makeifs change, so that branch can be closed once merged.

I'm convinced this isn't the best way to do things, given that the tests are now dependent on Charlotte, but it seems like a waste of effort to not use Charlotte.

If there's a way to separate out the tests so that only the interpreter tests depend on Charlotte, that would probably be ideal.

[MikeInnes]

I think the basic interpreter should just have a set of core sanity checks with some simple hand-written WASM. The interpreter logic should be simple enough that that's all that's needed.

We'll put the Julia equivalence tests in Charlotte, and if they reveal bugs then the MRPs can go here.

[sjorn3]

I've rebased on top of the parser, improved the parser and created some tests for parsing and interpreting. I'll add support for modules before it gets merged, but I think it's working as desired.

I'll also need to clean up the commits a bit, but if they're getting squashed it doesn't matter too much.

[tshort]

I wouldn't worry about the commits and just rely on squashing. It may help to draft one commit summary to go with the squashed commit.

[sjorn3]

Have now added some support for modules.

And just for fun (Though it would make a good test over on Charlotte) I got this minor monstrosity to work:

fib_, this_, pow_ = [fib => Tuple{Int}, this => Tuple{Int}, pow => Tuple{Int, Int}] |> wasm_module |> string |> WebAssembly.parsebrackets |> WebAssembly.module_ |> WebAssembly.interpret_module

Where fib_ and the rest are just callable functions, obtained by taking fib, compiling to a string and then working back up again. This also shows Call being interpreted properly as this calls pow and fib calls itself.

[tshort]

Cool!

[sjorn3]

Okay, I've rebased on master and given the code a once over. There's more that can be done but I think what's here is already useful elsewhere, and is in a good state for merging.

---

Commit Message:

Added the initial form of a parser (for wast) and interpreter. The parser is suited to parsing output from Charlotte in its bracketed form, and is used to load in wast to test the interpreter. The interpreter is able to convert the internal representation of wast into a callable function.

---

There's also a minor change that needs to happen on the Charlotte side to allow the recursion tests to work. I'll put it into a pull request.

[MikeInnes]

Looks good to me.

One minor comment, but do we need all the wasm snippets in separate files? Might be nice to have something like a wasm""" string macro embedded where they are used in the tests.

[sjorn3]

I think that should be the change you were looking for @MikeInnes.

[tshort]

@sjorn3, are you waiting on this? Pinging @MikeInnes.