-
Notifications
You must be signed in to change notification settings - Fork 2
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
seminaive propagators #5
base: master
Are you sure you want to change the base?
Conversation
huh, it looks like you've done a big refactor that removes the |
Yes, the R value didn’t add much. But I expect your work could be a drop-in replacement for I am wondering if anything more elaborate than the naive propagator should live in a separate package – easier to refine independently, and maybe useful to people who don’t trust my pure API anyways. Or maybe it is overkill. |
class (Eq a, Bottom a) => ChangeAction da a where | ||
-- laws: | ||
-- 1. update (kickoff x) bottom == x | ||
-- 2. (update dx x == y) implies ((x == y) == noChange dx x y) | ||
update :: da -> a -> a | ||
kickoff :: a -> da | ||
noChange :: da -> a -> a -> Bool | ||
noChange dx x y = x == y | ||
class ChangeAction (Delta a) a => Change a where type Delta a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I’d also expect (maybe as a later refinement) a way to efficiently assembles deltas. I.e. a Subgroup or Monoid constraint on da
, and a law
update dy (update dx x) == update (dy <> dx) x
|
||
import Data.POrder | ||
|
||
class (Eq a, Bottom a) => ChangeAction da a where |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that I replaced Eq
with the check in POrder
. This way we can deal with sets whose elements can’t be compared (it suffices to check the size of the sets).
I've taken a stab at updating the seminaive propagators to avoid the race condition you mentioned. This involves remembering state for each propagator that might need to access the previous version of its inputs. This linearizes the delta-processing for each relation between propagators; you can think of each one as a little stateful process that reads deltas from its input propagators and writes to its output.
This PR isn't really "ready" yet; I haven't implemented feature-parity with regular
Data.Recursive.Set
functions. I'm also not entirely confident I've avoided all race conditions, I'm pretty new to concurrent programming in Haskell. I'm not sure whether you're interested in this approach; feel free to close this PR if not. But if you are, I'd be interested in any feedback you have.