why does all the french make me want OCaml to be renamed laissez-faire? :-)
On Fri, Jun 26, 2015 at 1:40 PM, Thomas Leonard <[email protected]> wrote: > On 26 June 2015 at 13:29, Daniel Bünzli <[email protected]> > wrote: > > Le vendredi, 26 juin 2015 à 11:18, Thomas Leonard a écrit : > >> let x, set_x = S.create 1 > >> let () = ignore (S.map print_int x) > >> let () = Gc.full_major (); List.iter set_x [2; 2; 3]" > >> > >> Under the ref-counting scheme, this program would always print > >> nothing, > > > > Yes. > > > >> because the map signal's refcount is always zero, and it therefore > never connects to the x signal. > > > > Yes though I wouldn't see it at "never connects" (at least from an > implementation point of view). The `Smap print_int x` call will put the > resulting signal into x's dependents (hence "connect" from my point of > view), increase `x`'s ref count and the created signal will have a ref > count of 0. > > Why not delay the connection until the map signal is ref'd? Otherwise > (as you note below) it will leak. > > > Now what will happen is that on the first set_x, this signal will end up > in the update step but since it has a ref count of 0 we don't update it and > remove it from x's dependents and decrease `x`'s ref count by 1. (In fact > I'm now realizing that ref count is mostly the length of a node's > dependents array, except for the ability to specify that you would like to > retain/release or subscribe/unsubscribe a node at the leaves) > > > > Now if you had increased the ref count through a hypothetical > S.subscribe call: > > > > let x, set_x = S.create 1 > > let () = S.subscribe (S.map print_int x) > > let () = Gc.full_major (); List.iter set_x [2;2;3] > > > > It wouldn't be Gc'd. The only thing I slightly fear with this is that we > could get hard to track down leaks: suppose a program does what your did > first, and that the x never gets set, the `ignore`d signal will never be > gc'd. Though I don't know if that's really relevant in practice. > > > > One option could be to introduce the subscribe/unsubscribe scheme in > react and force people to use it but it would do nothing on platforms with > weak refs and implement the ref counting, OTOH I tend to prefer if the > backends have exactly the same behaviour. For example with your original > example in one backend you would see the Division_by_zero (which I still > consider fair game, w.r.t. semantics) and in the other not and that would > be annoying when you switch backends. > > > >> I guess the more complex case is S.bind, where the bind returning a > >> signal would increase its count (and decrease the count of the > >> previous signal), requiring signals to register and unregister > >> themselves during evaluation. It sounds like it could work, though. > > > > Yes the dynamics is always the tricky part and should be carefully > considered, the other tricky part is the delayed nodes used to implement > recursive definitions. But I'm certainly to at least try to do this in the > future as the situation seems to be really too impractical on JavaScript if > you do dynamics (which is when it eventually becomes *interesting*) and > there doesn't seem to be any way of implementing weak refs semantics in > JavaScript in the forseable future. > > > > Also it has always been my goal to have an implementation of FRP that > allows to experiment with it to its full extent without being bothered by > efficiency issue, now it seems that leaving the life-time of dangling nodes > in the hands of the gc can be problematic in practice so we'll see if we > can fix that (though I won't change the semantics, at the risk of repeating > myself that division by zero should be handled...). > > > > Best, > > > > Daniel > > > > -- > Dr Thomas Leonard http://roscidus.com/blog/ > GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA > > _______________________________________________ > MirageOS-devel mailing list > [email protected] > http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel >
_______________________________________________ MirageOS-devel mailing list [email protected] http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel
