Support static data about schism HOT 4 OPEN

I think the ideal solution goes like this. I think these points correspond to PR-sized chunks.

1. We add a new AST kind, literal, and we use it for all literals (booleans, numbers, characters, strings, symbols, quoted pairs, etc). We extend the simplifier to be able to know how to get e.g. a raw i32 from a number. Late in the compiler we convert into calls to %make-false, %make-number, and so on.
2. Instead of converting to %make-number calls, the compiler changes to collects all literals, de-duplicates them, then assigns each one an index. Literals lower instead to table.get calls of the corresponding index. We add a start function to Schism's modules which initializes the table by calling into the runtime to allocate the JS string/number/pair/whatever.
3. We add support for more sensible string literals. For that we will ideally need a data section, and to give schism a memory again; strings will be created by a run-time callout to (%make-string offset-to-bytes byte-len).

This approach also has the advantage of testing the table.get etc instructions from the anyref work.

from schism.

This plan sounds good to me!

As an alternative to table.get, could we use globals instead? Overall, I think tables are a better solution (we'd end up with a ridiculous number of globals!), but perhaps globals make sense for particularly well known values like #f and #t? I'm guessing table.get these days is pretty fast, but I suspect it has a bounds check that globals might not.

I think bringing back the Wasm memory opens up some other interesting possibilities. I've been thinking a little about how we'd want to do bytevectors (#37), and keeping the contents in linear memory might let Schism do some relatively fast processing while staying purely within Wasm. Then we could do a bulk copy out into JS when needed.

from schism.

This seems finished now.

from schism.

Well, except for the newer string literal format...

from schism.