(2012/04/19 7:32), Daniel Bünzli wrote:
Yes because the semantics of [e] is violated, it has three values at the same
time, the current value during the update cycle, the value 1 and the value 2.
Now suppose I reason about the semantics of [e] in this program, it has a
well-defined outcome *for [e] itself* if I send it a value [v]. However if you
now add a new module that uses [e] and does :
Thank you for helping me understand with your explanation.
If I understand correctly sending [v] to [e] immediately during update cycle
are violate the semantics because it cause more than one values on one event at
the same time.
Using React,
let e, sender = E.create () in
let e' = E.map (fun x -> Queue.add q (fun () -> sender 1); x + 1) e in
let e'' = E.map (fun x -> Queue.add q (fun () -> sender 2); x + 1) e in
does this code violate the semantics of events? If so, PEC is also unsound.
I'd like to know PEC is unsound or not.
> So if I understand correctly you are doing manual memory management via (un)subscribe
of the leaves of the dependency tree and instead of having weak "forward" pointers from
events to their dependents you have regular "backward" pointers from events to the events
they depend on. Once these leaves are subscribed we can follow them backwards to find out
what their primitive event set is and understand what needs to be updated along the way.
Yes, exactly.
>It may be an interesting approach to avoid weak pointers but I'd need more thinking to
convince me it can correctly handles all the dark sides of leaks, fixed point definitions,
signal initialization and dynamically changing dependency graph. By the way you still need
to update the events in the correct order/and or only once to prevent glitches, how do you
achieve that ?
To prevent glitches, PEC distinct one update cycle to another by time identity.
And calculated results are cached for same update cycle.
Update order is straight forward. Just follow from leaf to primitive source
event.
It's not problem because only one primitive value changes at one update cycle.
Best Regards,
Ogasawara
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
