Re: mirage + froc = self-scaling?

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

Le mercredi, 10 avril 2013 Ã 12:57, Richard Mortier a Ãcrit :
> aside: on the memory point, would it be a reasonable way to think about this 
> that React uses weak refs to avoid memory leaks, while Froc uses strong 
> references *but* automatically allows any inside a bind to be collected every 
> time their value changes (so Froc is kind-of implementing it's own GC at a 
> library level).

I don't know enough about froc's implementation and api to be able to precisely 
comment on that.  

> the part i'm having to work harder to understand is control dependencies (and 
> tbh, fix points in React, which feel not unrelated...).
What don't you understand in fix points ? and in which sense do you feel they 
are related to control dependencies ?  

> > let b = x >>= fun x -> return (x = 0)
> > let n0 = x >>= fun x -> return (100 / x)  
> > let y = bind2 b n0 (fun b n0 -> if b then return 0 else n0)  
> >  
> > doesn't "work" (may divide by zero). But this  
> >  
> > let b = x >>= fun x -> return (x = 0)  
> > let y = b >>= fun b -> if b then return 0 else x >>= fun x -> return (100 / 
> > x)
> >  
> > suddenly does.
> sorry, my cs theory is not so hot -- could you expand how referential 
> transparency is broken here?

Well if you substitute `n0` by its definition in `y` you get the second 
program. However both programs do not have the same behaviour [1]. As I said, 
the same thing can happen in react (as the signals are not created at the same 
time in the first case and in the other), however I think the problem is more 
acute in froc because of control dependencies. Basically in react the 
behavioural differences may be on a prefix of the timeline, in froc it's much 
more convoluted as signals implicitely have stopping times (see below).  

> just to clarify -- you mean "disconnected from the system *during an update 
> cycle*"?
Yes.

> > It would be interesting to actually work out the precise semantics of that 
> > but I suspect that reasoning about such a system becomes significantly 
> > harder since the obvious application is to enable/disable side-effects and 
> > you no longer have obvious timelines for these signals.
> again, could you expand what you mean here?

In react the semantics is simple, once a signal is created it's behaviour is 
defined at *all* further points in time. In froc it's not the same, a signal 
may be defined on only during an *interval* of time (because of control 
dependencies).  

This means that if you want to reason on effectful events and signals (see 
below for what I mean) in froc you also have to derive/reason about their 
stopping time. I prefer to have signals that are well defined at all point in 
time after their creation. This means that you may have to bundle the disabling 
of its side effect in its own definition [2], but at least you can reason on it 
easily by applying the denotational semantics on its defining expression --- 
for example to prove by equational reasoning that after a particular event 
happened, the side effect will no longer happen.  

> that is, by "side-effect" do you mean manipulation of the FRP DAG
No. I mean effectful events and signals, that is events and signals that 
perform a side effect when their value changes (see [3] for more info about how 
they are treated in react).  

As an aside I think that usually it doesn't help to think of frp in terms of 
dag and update cycles, that's really an implementation detail. Unfortunately 
since react is an frp *engine* and not an *api* to a problem domain I do have 
to talk about that a lot in the documentation. But would you like to approach a 
problem with frp, I think you should first try to determine your primitive and 
outputs and give them a denotational semantics as values that depend on time 
and use that as the guiding principle for designing your system. Frp should be 
really thought about in terms of its denotational semantics not in terms of its 
implementation, see this answer [4] about the inventor himself.

Best,

Daniel

[1] http://en.wikipedia.org/wiki/Referential_transparency_(computer_science)
[2] In the example above this means that you would always need to protect 
against division by zero in n0.
[3] http://erratique.ch/software/react/doc/React#sideeffects

[4] 
http://stackoverflow.com/questions/1028250/what-is-functional-reactive-programming