This would be the next major improvement on the Esty side.
The output would follow the same template as the spreadsheet tool:
DAG representations
Distribution of each node
Download link for raw data
Distributions of each node
A version of this that I could do without constructing the DAG is to just take the final value of all the Starlark globals. This would be an easier start / incremental step.
DAG
Requires some thinking on exactly how the DAG should be constructed, e.g. how should loops and variable reassignments be handled?
How does this map onto the CS concept of data dependency graph (does it have a single definition?).
One solution is to disallow reassignment, loops, and conditionals in the globals namespace (leveraging the fact that these are features of starlark-go). Then it's much less ambiguous what the DAG should be.
I will need to use the Go package for Starlark abstract syntax tree (AST) construction, to walk the AST and construct the DAG: https://pkg.go.dev/go.starlark.net/syntax
This would be the next major improvement on the Esty side.
The output would follow the same template as the spreadsheet tool:
Distributions of each node
A version of this that I could do without constructing the DAG is to just take the final value of all the Starlark globals. This would be an easier start / incremental step.
DAG
Requires some thinking on exactly how the DAG should be constructed, e.g. how should loops and variable reassignments be handled?
How does this map onto the CS concept of data dependency graph (does it have a single definition?).
One solution is to disallow reassignment, loops, and conditionals in the globals namespace (leveraging the fact that these are features of starlark-go). Then it's much less ambiguous what the DAG should be.
I will need to use the Go package for Starlark abstract syntax tree (AST) construction, to walk the AST and construct the DAG: https://pkg.go.dev/go.starlark.net/syntax