Re: mirage + froc = self-scaling?

[Daniel BÃnzli <daniel.buenzli@xxxxxxxxxxxx>]

Thanks for your insights.

> What I'd like it to look like:
> 
> ~~~~~~~
> create: unit -> ('a pusher * 'a t)
> write: (\exist 'a . ('a * 'a pusher)) list -> unit (* push several
> values on several primitive signals instantaneously *)
> ~~~~~~~


Actually I was more going towards that kind interface. The thing is that React, 
contrary to Froc doesn't use global data structures, so I was for sure not 
going to have a froc-like interface. The data structure used during and update 
cycle needs to be witnessed somewhere. So the idea was to expose a `step` type 
that represents an update cycle:

  module Step : sig
    type t
    create : unit -> step
    perform : step  -> unit
  end

  val S.create : unit -> 'a signal * (?step:Step.t -> 'a -> unit) 

with the idea that if you use the ~step arguments is schedules the value of the 
primitive to be one provided on this step. This may not be optimal maybe Step 
should be a "Steps", so that you can definitively plugin a Steps structure on 
the primitive setter and forget. 

This could also be an opportunity to build in a mechanism for primitive update 
from the update cycle -- so far I always told people to put the updates in a 
queue and dequeue after the step. In fact if the signal setter function no 
longer automatically create an update cycle that is we change the signal setter 
signature to a concrete Step.t -> 'a -> unit, this becomes trivial. But I need 
to think about what happens with fixed point operators, as those automatically 
create steps. It may also make libraries less compositional (if they impose 
their step). 

Regarding the thread-safety rule [1] I think it would still be rather simple: 
Let uset(s) be the set of events and signals *including the primitive ones* 
that need to be updated whenever `Step.perform s` is invoked. Performing two 
steps s and s' concurrently is only allowed if uset(s) and uset(s') are 
disjoint, otherwise the steps executions must be serialized.

So maybe the idea of react that the setter function automatically creates an 
update cycle was a bad one. Having an explicit steps type to drive the system 
may be better. 

But it's a change I need to get right, so I won't rush. I'm however very 
interested in talking in person with you Raphael (or anybody who has some 
experience or toughts about frp in Cambridge) about this during the following 
two months.

Best,

Daniel

P.S. This becomes a little bit OT for mirage maybe we should try to find 
another venue to discuss these things. Maybe an ocaml-frp mailing list ? 

[1] http://erratique.ch/software/react/doc/React#update