Author here. The library is a toy project, it's far from being complete. Many things including macros are missing. Implementation style is derived from ClojureScript's compiler
It may be a toy, but I've been looking at doing very similar things at work. We have an optimizing compiler for spreadsheets, and many of the better optimizations are implemented as clojure syntax transforms (since Clojure was our first working target), so lowering that representation rather than selecting another is an attractive option, especially when compared to (for example) generating LLVM IR or code for some high level language.
What is even a compiler for spreadsheets? In spreadsheets you still have an AST, or is it a different structure? Is there any fundamental property of spreadsheet code that enables specific optimizations?
It's more that it necessitates certain optimizations, rather than enabling them.
You need to figure out how and when to merge expressions, when it's worth it to extract a loop where the same expression needs to be compiled as two or three variants, because there are invariants between all but two or three of the invocations. You also must decide which collections you want to create out of the reference soup, when you can alias/discard collections and values, how to hoist predicates (for IF and SWITCH), when you can avoid type coercion. For small workbooks, just using tagged unions in a 2D array, plus a string pool, will suffice, but our sheets are so big that we can't afford that.
This looks great! Thanks for building it. Any plans on adding support for Collections and their functions? If that were to be added, I'd have a lot of use cases for this library already.
Does the order of the sections matter in the text format?
Been poking a bit here and there at a wasm binary parser and know in that format they're supposed be in order (with custom sections sprinkled wherever) but can't recall seeing anything about the text format order.