search

joshuabowers / graphca

A graphing calculator and analytic calculus engine
MIT License
0 stars 0 forks source link

Evaluating variables #5

Closed joshuabowers closed 2 years ago

joshuabowers commented 3 years ago

Once a variable has been assigned an expression, those expressions need to be stored somewhere and be usable in further evaluations. Whereas the linked issue is specifically interested in syntax, this issue is concerned with semantics: where is the data stored, how can it be evaluated, how can it be referenced in further expressions.

Pegase accepts a set of options to most of its parsing and visit functions. Amongst these options is something called 'context', which can be strongly typed via a secondary type parameter on the template literal peg tag. If my understanding of context is correct, it can be used to both define the assignment of variables---e.g. act as a semantic side-effect of parsing---as well as access their values later on.

Assuming this interpretation is correct, it would be sufficient to define an object which allowed identifiers to be bound to an expression. While the built-in Map container would make sense, it might be desirable to to embellish the context: if every variable had a timestamp associated with when it was set, one could query the context for the set of variables defined within a specified time range. This would allow variables to be redefined without necessarily destroying older values. Primary motivation: being able to have a singular global context which can be used in selectors for rendering components in a react front-end.

When a variable is assigned, its expression value is ran through evaluateVisitor then stored via its name in the above context object. When a variable is referenced, the context object is accessed to grab the stored expression, which the variable node within the currently evaluated tree is replaced with.

Implication: if it is desirable to keep expressions in a fashion that minimizes complexity on the redux store, stored expressions are either going to need to be kept in a stringified form within the redux store---e.g. under state.terminal.context---or will need to be stored as a Node object in some other object. (The assumption being that a parsed expression---e.g. a pegase Node---is derived data built from state, not state itself.)

Storing the expression as a string has complications: it would need to be reparsed while in the process of parsing, and other context might be likewise inaccessible without further processing. However, full context for the app cannot exist as purely derived data in selectors: context could potentially be shared by many evaluated expressions.

joshuabowers commented 3 years ago

bbcf4c11af26cc375902b5c6ff07f0561f8cb15e has the definition of a container to dump context into. Should just need to wire it up to the appropriate parts of the parser and visitors.