Re: mirage + froc = self-scaling?

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

Le mercredi, 1 mai 2013 Ã 21:07, Anil Madhavapeddy a Ãcrit :
> Just to pick up on this point, the issue is that I think we don't really know 
> if FRP can actually be used at scale. Or at least, noone has tried yet in 
> OCaml (some of the Javascript versions are reasonably well used for UI 
> reactive programming).

To be honest I don't see why it couldn't actually scale. Sure it's going to be 
slower than pure imperative programming, the datastructure tracking the 
dependencies is not free -- but still even that is not entirely clear since frp 
may mean that you compute less because of the very fine dependency tracking.  

However if you actually need an observer mechanism in your system, I would 
highly suggest that you use frp, as the naÃve OO way of doing this is usually 
unsound with what you want --- glitches, needless computation and too coarse 
dependency tracking that means that you have to program defensively against 
spurious updates (recheck the state of the system before proceeding when 
hollywood calls you).

One thing to keep in mind though is that FRP is really a different kind of 
programming, it's dataflow programming and you really need a different mindset 
(see e.g. the example in this presentation slides where we are interested in 
defining the `elapsed` variable of a countdown ui [1]). But at least you 
program with values that are well defined and compositional, not some kind of 
reference mutated by a sour callback soup.  

On my side because of my work on Vg, I have been thinking a little bit about 
React w.r.t. to frp's original motivation -- functional reactive animation [1] 
(animation = Vg.image React.S.t). And I think React may need to evolve to 
support that idea in a non toy manner.  

The problem is that React has the premise that there can be no two *primitive* 
signals/events (inputs to the system) that happen at the same instantaneous 
time. Each change to a primitive triggers an update cycle that you have to 
consider atomically. In animation you are usually not interested in updating 
that image signal beyond 60Hz, so if you change say three colors of a picture 
between two frames you don't actually want to recompute trice the picture.

Now you can circumvent this problem within react itself:

let on_frame, redraw = E.create ()  
let resample prim = E.hold (S.value prim) (E.sample on_frame prim)  

but it feels artificial, you'd have to `resample` all your primitives before 
using them to define your image, and could become inefficient if you have many 
primitives.  

The good news is that this limitation is purely artificial and react can 
perfectly be adapted to support simultaneous primitive updates, I just need to 
devise an api that exposes an abstract type to some parts of react's internal 
mechanism. But again I need to think more about this and write code.  

This with the other goal I have to make React leak less in the browser and 
change the signature of the signal switching combinator could lead to an (only 
slightly) incompatible 1.0 release or React.  

Best,

Daniel

[1] http://erratique.ch/talks/ocamlum-2010
[2] http://conal.net/papers/icfp97/