Re: [Caml-list] [ANN] PEC ver. 1.1

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Le mercredi, 18 avril 2012 à 03:59, Satoshi Ogasawara a écrit :
> > What's the semantics if you send two different values to an event during an update cycle ?
>  
> They fires two different event if you send two different value to an event
> even if same update cycle. Events send are stored in an event queue,
> and they will be poped by 'run' function just like GUI event loop.


Ok. I would just like to point out that you can do exactly the same with React. However React doesn't integrate that functionality, the client has to implement it. Mainly for two reasons.  

1) Thread-safety and compositionality. React has no global data structure.

2) Semantic issues. As soon as primitive events are triggered by other primitive events you run into the problem of multiple occurences of the same event during an update cycle. Now given the synchrony hypothesis of update cycles (an update cycle is instantaneous), this is a violation of the semantics of events (an event has at most one occurence at any given time t). And then people ask you if you can somehow manage the order of updates in an update cycle and then you are not doing FRP anymore, you are doing RP. By loosing the F you also loose compositionality and the equational reasoning tools provided by the denotational semantics of events.   

> > I'm not sure how that's different from react. If an event has no dependents (by which I understand your "subscribed"), react doesn't hold any pointer either.
>  
> React constructs 'heap' to hold dependency graph inside the library.
> let e' = map (fun x -> x + 1) e, the e' and e are weakly pointed by the heap.
> PEC doesn't have heap structure in the library. This is a difference.
>  
> This difference is important if you want to translate the OCaml event
> combinator to javascript because javascript doesn't have weak pointer.


To be precise React constructs a heap only during an update cycle. Now I guess you must have some kind of similar data structure encoded since if you don't update your events in topological order of the dependency graph, you'll have glitches and again violate the semantics of events.

Regarding the absence of Weak usage I'm curious in how you manage the garbage collections of events that depend on others.  
  
> > How is that different from react's E.switch/S.switch ?
>  
> Almost same except all signals are created though react's S.switch at initializing.
>  
> It's convenient to design library for dynamic event driven systems. For example,
> let me assume a signal of window size property.
>  
> type window = {
> size : (int * int) signal;
> }
>  
> If you want to change the dependency of window.size after initialize the window
> keeping signals depends on the size unchanged, there is no way except making switch
> event at initializing.
>  
> type window = {
> size : (int * int) signal;
> size_switch_event : (int * int) event event;
> }
>  
> I feel it's not convenient. So I decided to embedded the swith_event to inside of signals.

Best,

Daniel