You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
At the moment, we've got a Script that acts as a static representation of combinations: an Execution maintains a pointer into that, of some sort. The Script doesn't change, and as the Execution dives into the combinations, it maintains a ->stack attribute of combinations-in-progress.
The alternative: copy the Script for each clone of the Execution, store it as a part of the data-type, then as the Execution is realized, we gradually replace nodes with the results of their respective combination:
This precludes the necessity of a stack entirely. However, implementationally, it'd require a lot more copying.
(Also, this is kinda implementation-details-y. But, at the moment, the spec is an ugly hybrid of implementation-details and operational-semantics. So, an easier-way-to-understand-it description is the purpose of this issue.)
The text was updated successfully, but these errors were encountered:
At the moment, we've got a
Script
that acts as a static representation of combinations: anExecution
maintains a pointer into that, of some sort. TheScript
doesn't change, and as theExecution
dives into the combinations, it maintains a->stack
attribute of combinations-in-progress.The alternative: copy the
Script
for each clone of theExecution
, store it as a part of the data-type, then as theExecution
is realized, we gradually replace nodes with the results of their respective combination:This precludes the necessity of a
stack
entirely. However, implementationally, it'd require a lot more copying.(Also, this is kinda implementation-details-y. But, at the moment, the spec is an ugly hybrid of implementation-details and operational-semantics. So, an easier-way-to-understand-it description is the purpose of this issue.)
The text was updated successfully, but these errors were encountered: