Le jeudi, 19 avril 2012 à 10:59, Satoshi Ogasawara a écrit : > 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.
Yes. > 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? Yes. It has the same problem. Let's start with : > let e, sender = E.create () in > let e' = E.map (fun x -> Queue.add q (fun () -> sender 1); x + 1) e in Since the thunk is delayed to be executed after the update cycle we *could* say that an occurence of [e] at time [t] defines the occurence of [e] at time [t + dt]. Note however that this is a bad idea, the right way to solve these problems is to use fixed point operators, see [1]. Now this is all fine, during the update cycle, which is made under a synchrony hypothesis (i.e. it takes no time, see [2]), we are defining the occurence of [e] at time [t + dt] as being 1. So far so good. But now we change the program and add > 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 This is not fine at all, during the update cycle, which again, takes no time, i.e. everything therein happens simultaneously at time [t], we are defining the occurence of [e] at time [t + dt] as being 1 and 2 at the same time. A schizophrenic event which obviously violates the semantics of events since an event must have at most one occurence at any given time [t]. So basically when you allow feedback from primitive events to primitive events you have to be very careful. Maybe that's needed in practice, again, I don't have enough experience to assert that, but if you do it you should make sure that the semantics of events is not violated. > If so, PEC is also unsound. > I'd like to know PEC is unsound or not. PEC may not be unsound as a whole. However the idea that you can just send to primitive events during update cycles and not bother is unsound with respect to the semantics of events as soon as you send two different values to the same primitive event. > 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. Right. But you still have to maintain some kind of mapping between the primitive event and the leaves they may influence to know which ones to update when the corresponding primitive event occurs. Do you store that in the primitive event itself or do you use a global data structure ? While I'm not very fond of the sub/unscribe part I think it's an interesting implementation and may try, once I get some time, to adapt it to React to see what we can get from it (I also think that the resulting implementation could be much simpler). One can in fact argue that using React you also have to do the same manual management by having to keep reference on leaf events to avoid them being gc'd. The difference is that PEC trusts the client to perform unsubscribes correctly to avoid leaks while React allows not to bother about that at all (but Weak pointers have their cost). Besides it may be the case that in practice sub/unsuscribe calls are not that plentyfull; I would count one subscribe and no unsubscribe in the breakout.ml example of React's distribution. Best, Daniel [1] http://erratique.ch/software/react/doc/React.E.html#VALfix [2] http://erratique.ch/software/react/doc/React#simultaneity -- 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
