[microcolonel]

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.

[6Typos]

Going offtopic, but...

>We have an optimizing compiler for spreadsheets

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?

[microcolonel]

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.