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

Grid- and position-dependent output patterns in all statements #7

Open
kaya3 opened this issue Sep 4, 2022 · 1 comment
Open

Grid- and position-dependent output patterns in all statements #7

kaya3 opened this issue Sep 4, 2022 · 1 comment
Labels
bug Something isn't working

Comments

@kaya3
Copy link
Owner

kaya3 commented Sep 4, 2022

Currently, all statements do not support output patterns which depend both on the current grid state and the match position. The reason for this is that either the output patterns are computed just once each (so they must be valid for all match positions) or they are computed in the loop which applies rewrites (so the grid state may be different to the one for which they should be evaluated). The best solution is probably to allow a separate "write buffer" for the grid, so that the old grid state is still available.

Minimal example (playground link):

grid [BRGU]
symmetry "none"

# works with 'one' but not 'all'
all: [B] -> (
    [R] if at.x % 2 == 0
    else [G] if count [R] > 10
    else [U]
)
@kaya3 kaya3 added the bug Something isn't working label Sep 4, 2022
@kaya3
Copy link
Owner Author

kaya3 commented Sep 5, 2022

Another possible solution, avoiding the extra buffer, is to defer the call to gridN_update until all writes are done - expressions which depend on the grid state don't depend on it directly, rather they depend on things derived from the grid state which, because gridN_update has not been called yet, will still represent the correct state for those expressions to be evaluated from.

That said, this may require calling gridN_update on a much larger area than necessary, if there are only a small number of rewrites, so it could be much slower; and there are probably other situations where the extra buffer is needed (so maybe the buffer will exist anyway).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant