Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reactions in simulation may be fired despite its preconditions being violated #75

Open
robotlolita opened this issue Feb 27, 2022 · 0 comments
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.

Comments

@robotlolita
Copy link
Contributor

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:

when X simulate-turn, if X won do
  fact state--won state;
  game log: "[X name] won!";
  game update;
end

when state--on-going state, X is player, if not (X won), not L at: C mark: empty do
  fact state--draw state;
  game log: "It's a draw!";
  game update;
end

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.

@robotlolita robotlolita added error Something is confusing, misbehaving, or harmful. s:1 moderate This is bad. We should deal with this as soon as possible. c:vm Changes to the VM, compiler,, or language semantics labels Feb 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
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.
Projects
None yet
Development

No branches or pull requests

1 participant