> some remarks to "get there": it must be/feel fast like native Excel, Sublime Text or at least VS code.

As someone who is working on an Excel compiler, I can tell you it's challenging to make it very fast.

Is your compiler running on an interpreted language? I think to make this sort of product fast requires JIT compiling the users expressions, and doing some sort of whole program analysis to pull out the dependencies between cells.

I do whole program analysis, and the host is not interpreted. The costs are mostly about the data structures used to store the intermediate values. Automatically selecting whether to make some values contiguous or not is difficult, and the types are a bit complex (basically option types).

The sheets I'm working with have around a million expressions, and there are large sparse regions, so the data structures have to be a bit compact.

I also think it would be valuable to autoconvert long lines (rows or columns) of similar formulas into a mapping on an array. That would require some level of shape analysis on the excel file.

That is in fact the first step, we have around 800k instances, but only around 1500 unique combinations of dependency shape and expression, which makes a big difference.

Sounds interesting, have you published any more details anywhere?

Not yet, gotta do our jobs first, then we can have the candy. :- )

I would like to do a write-up about it at some point though, if for no other reason but to show the Open Document or LibreOffice people what could be improved about the formats.

Agree on the speed.

Not every programming language is suitable but ClojureScript would probably work (no plans to support it right now though, gotta finish this one first!).

Considering hiding the boilerplate in the text pane.

Thank you!