In this case, I was first seeing what could be done with basic Scheme algorithmic programming language mechanisms (e.g., using procedures and the magic of toplevel definitions).
Then, after seeing how tax form logic ended up that way, one direction would be to define a DSL that makes that easier to work with. For example, if we find everything can be implemented as these procedures, or with maybe with an additional concept (such as to handle cycles like in the article), a simple first step DSL might be another s-expression language that has magic variables that are more akin to spreadsheet cell references, in that the dependencies are evaluated in order. And it might also do things like populate a hashtable with the cached values for application use (e.g., PDF form-filling). That DSL might be implemented as a simple `syntax-case` or `syntax-parse` transformer. If that works and could, we could optimally make it more palatable/marketable/politic by defining a keywords-and-whitespace grammar that parses by transforming those syntax objects to syntax objects in our intermediate s-expression DSL (which transforms to the basic Scheme code approach we worked out originally).
neilv|2 years ago
Then, after seeing how tax form logic ended up that way, one direction would be to define a DSL that makes that easier to work with. For example, if we find everything can be implemented as these procedures, or with maybe with an additional concept (such as to handle cycles like in the article), a simple first step DSL might be another s-expression language that has magic variables that are more akin to spreadsheet cell references, in that the dependencies are evaluated in order. And it might also do things like populate a hashtable with the cached values for application use (e.g., PDF form-filling). That DSL might be implemented as a simple `syntax-case` or `syntax-parse` transformer. If that works and could, we could optimally make it more palatable/marketable/politic by defining a keywords-and-whitespace grammar that parses by transforming those syntax objects to syntax objects in our intermediate s-expression DSL (which transforms to the basic Scheme code approach we worked out originally).
There are other valid ways (say, you want tax law logic to be definable dynamically at run time). Though some involve `eval`, which I discourage. https://lists.racket-lang.org/users/archive/2014-July/063597...