Re: mirage + froc = self-scaling?

[Ashish Agarwal <agarwal1975@xxxxxxxxx>]

My original suggestion was to summarize concepts like FRP and write tutorials about them on ocaml.org. Whether FRP scales or not is unimportant. Maybe it doesn't, but still FRP is a widely discussed concept and there are multiple OCaml libraries supporting it. Thus, I think ocaml.org could include content about it.

Yes.. this is way off topic. The main OCaml List is sufficient for this topic.

On Thu, May 2, 2013 at 6:15 AM, Daniel Bünzli <daniel.buenzli@xxxxxxxxxxxx> wrote:

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