Re: mirage + froc = self-scaling?

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

...responses inline, following a few hours interesting reading that i suspect i 
haven't *completely* internalised yet... :)

On 9 Apr 2013, at 23:50, Daniel Bünzli wrote:

> Le mardi, 9 avril 2013 à 10:16, Richard Mortier a écrit :
>> having said all that, to turn your question around, are there strong reasons 
>> to prefer React over Froc? i'm still learning about FRP so happy to have 
>> discussion about this :)
> 
> Well, I'm going to be biased. But here it goes.  

so to summarise, React's benefits: are specified denotational semantics, and no 
global data structures; but React can only guarantee no memory leaks in 
environments that support weak references (which does not include JS until 
ECMAScript 6 is adopted).

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).

the part i'm having to work harder to understand is control dependencies (and 
tbh, fix points in React, which feel not unrelated...).

> 4) Regarding the question of control dependencies, ... One thing that strikes 
> me in Jake's example [7] is that this:
> 
>  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.

> First note that referential transparency is broken here (similar examples 
> exist in react, the semantics tells you why this is the case -- signals get 
> only a timeline once they are created -- it seems however more prevalent in 
> froc because of these control dependencies).  

sorry, my cs theory is not so hot -- could you expand how referential 
transparency is broken here?

> This also means that you have two kind of signals in froc, those that are 
> defined for all t once created like n0. This is similar to react (to be 
> precise, defined at all t until sometime after no longer needed by the 
> system). But you also have other kind of signals that have a limited life 
> span, those in that else branch, that may be disconnected from the system.

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

> 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? 

that is, by "side-effect" do you mean manipulation of the FRP DAG (whether 
directly by changing the DAG itself, or indirectly through some piece of shared 
state that i guess could include trying to feed in through a primitive 
signal/event)? if so, i can see how that becomes problematic if DAG 
manipulations overlap since ordering will be an issue and synchrony is 
violated; and i think your later suggestion of treating the DAG as building a 
transaction with all "side effects" pushed to the boundaries is one way to 
ensure that these bad interactions never happen. but are there other problems 
you see here?

-- 
Cheers,

R.




This message and any attachment are intended solely for the addressee and may 
contain confidential information. If you have received this message in error, 
please send it back to me, and immediately delete it.   Please do not use, copy 
or disclose the information contained in this message or in any attachment.  
Any views or opinions expressed by the author of this email do not necessarily 
reflect the views of the University of Nottingham.

This message has been checked for viruses but the contents of an attachment
may still contain software viruses which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.