| You may find SIAG (Scheme in a grid) interesting. It explores some of the same ideas: https://siag.nu/siag/ There's also been some work along these lines in Excel itself, although using the Excel formula language rather than Scheme. Excel now has both let and lambda, as well as a way to work with composite data structures in cells. https://www.microsoft.com/en-us/research/blog/lambda-the-ult... https://support.microsoft.com/en-us/office/let-function-3484... https://exceljet.net/dynamic-array-formulas-in-excel In general, I think your idea is sound. Almost since the beginning, Spreadsheets have had two major ways of operating on data - the formula language, which is automatic, declarative, and functional in nature, and commands (like on a menu), which are generally imperative and have to be explicitly invoked (or invoked through a separate macro language). Both have their places, but the functional language of formulas is nice for the same reason functional languages in general are appealing. There's also an easier ramp for users new to programming to progress from "=A1+B1" to more advanced sorts of operations (lookupus, etc.) without having to switch to a formal "programming language". However, aside from additional standard functions, the formula language half (in Excel, at least) was largely static since the 1980s - limited essentially to scalar data types, and no internal way for creating abstractions. This severely limited the range of what you could do with formulas, when compared to more complete programming languages, and forced a lot of functionality to be done in (more brittle) macros. So the direction you're going - broadening the power of what can be done with a spreadsheet language - is a useful one, and there's prior art to justify that the idea makes sense. |