Re: [Caml-list] Signals of signals in react

["Daniel Bünzli" <daniel.buenzli@erratique.ch>]

Hello,

Le vendredi, 8 mars 2013 à 10:43, Philippe Veber a écrit :  
> val bind_s : 'a React.signal -> ('a -> 'b React.signal) -> 'b React.signal

I guess the semantics you want is : [bind_s s sf]_t = [sf [s]_t]_t.

Well that doesn't seem unreasonable. I remember having pondered a lot about which switching combinators to take in the interface and I'm sure I must have considered at least :

switch_s : 'a signal signal -> 'a signal  
(* [switch ss]_t = [[ss]_t]_t *)

that would allow for a very easy implementation of bind (switch_s (S.map f s)).   

But if it didn't make it *may* be due to thorny signal initialization problems. If you look the signature of the current switch it's a way to force you to have to give an initial value. But a signal, once created, is supposed to have a value at each point in time, well with dynamic switching there are fine points to consider that I don't have in my head right now.  

> let bind_s s f =  
> let s' = S.map ~eq:( == ) f s in
> let init = S.value s'
> and changes = S.changes s' in
> S.switch init changes
>  
> So far it worked as I thought it would, but still I'm not really confident this is a safe use of signals. Does anyone see a potential pitfall here?
As a rule of thumb using S.value is never safe if you are inside an update cycle, this means that you may get problems if you use bind_s during an update cycle itself. Now sometimes it may be hard to find a counter example, as it may be hidden in the messy mechanisms needed to support fixed point combinators and dynamic signal creation.  I guess the problem would likely arise if s is itself created during the update cycle, in some cases it could not be initialized yet.  

It's a little bit irritating as what you want seems really sound to me, but I'm afraid you cannot implement it with the current interface without providing an initial value yourself.  

I don't have the time to investigate right now but I'll surely get back to it later to give you a definitive answer.  

Daniel
  
P.S.  
If switch_s can be implemented without problems I'll gladly incorporate it into as *the* S.switch, since the current S.switch would then just be:

sswitch (S.hold s es)

If you are interested you may want to have a look at react's imperative hell to see if it seems workable. Especially by considering/transforming the current S.switch combinator.