Reactions in simulation may be fired despite its preconditions being violated #75
Labels
c:vm
Changes to the VM, compiler,, or language semantics
error
Something is confusing, misbehaving, or harmful.
s:1 moderate
This is bad. We should deal with this as soon as possible.
Milestone
When the simulation runs, it computes the list of reactions only once for the current turn. However, if a reaction causes any effect it might invalidate further reactions that have been scheduled to fire. This means that the reactions would be fired incorrectly.
Consider the tic-tac-toe example in this repository:
Here, as part of the reaction to marking one of the cells, the game may either enter a winning or a draw condition. These separate reactions take care of that: if, at the end of one player's turn, the
X won
predicate succeeds, then we move the game to the winning state. But if we've exhausted all cells and found no winner, we move the game to the draw state---this further explicitness in checking for a winning condition is also necessary because Crochet does not guarantee any ordering between events.Now, the second reaction is problematic. We have more than one player, so each player triggers a reaction here when the game reaches a draw state, because neither of them will have won. As a result of reaching a draw state we move the game to "state--draw", but we also cause effects that show this on screen. In the tic-tac-toe example, this causes
It's a draw
to be logged twice, because we run the reactions sequentially but we compute them eagerly, before we fire all of them.The language could choose to not validate the preconditions after reactions, which would force users to rewrite their reactions with this in mind, and manually take care of multiple reactions firing. But that does not seem like a good direction, so it's quite likely that this will be solved by guaranteeing that reactions only fire if they're still valid.
The text was updated successfully, but these errors were encountered: