dhess
commented
11 months ago We may need to revisit this given more recent feelings that we should be doing evaluation in the frontend, rather than eval-as-a-service.
Open dhess opened 1 year ago
dhess
commented
11 months ago We may need to revisit this given more recent feelings that we should be doing evaluation in the frontend, rather than eval-as-a-service.
Currently, we store programs as:
Storing the current tree is an optimization: we could simply store the initial tree and replay the sequence of edit actions to arrive at the current tree, but we expect that the performance of this design would not be acceptable for interactive use. In any case, given that we have the current tree, the log's only use at the moment is for undo.
On the interactive evaluation side of things, there is no corresponding sequence or log of evaluation steps. The current evaluation API requires that the client send an expression that it wants the backend to evaluate, and then the server returns a whole new program state. This API is convenient for the backend: there is no reason to save any state related to evaluation, as that's a frontend problem. However, this API is problematic for a frontend implementation: not only does it require that the frontend know which redexes are available in the current evaluation state, it also isn't scalable for anything but the simplest toy programs, due to the very large trees that evaluation will inevitably produce.
We would like for the frontend a) not to have to know anything about Primer's evaluation model and b) to receive from the backend only the changes ("diff") that occur to the program's state when the student performs an evaluation step. Therefore, we'll need to change the interactive evaluation API ("eval mode"), and keep track of evaluation state in the backend.
It seems logical that there should be just a single "initial tree + changes" data type in the backend that could represent both changes due to edits and changes due to evaluation, so in our 2022-10-24 developer meet-up, we proposed that we should a) keep an evaluation step log on the backend for every student session (and here I mean "session" in the colloquial sense of browser session, not how we currently use that term internally in Primer's implementation), and b) have a single log that's capable of storing both edits and reduction steps.
(This unification would also open the door to caching evaluations in the database, but I'll file a separate issue for that as it's quite a bit more involved.)