[Caml-list] Signals of signals in react

[Caml-list] Signals of signals in react

[Philippe Veber]

[-- Attachment #1: Type: text/plain, Size: 900 bytes --]

Dear functional-reactive camlers,

In order to change the dependencies between signals dynamically, one can
use the switch function whose type is:

utop $ React.S.switch;;
- : ?eq:('a -> 'a -> bool) -> 'a React.signal -> 'a React.signal
React.event -> 'a React.signal = <fun>

However I often find myself wanting to write signals of signals, and I
wrote the following definition to cope with them:

val bind_s : 'a React.signal -> ('a -> 'b React.signal) -> 'b React.signal
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?

Cheers,
  Philippe.

PS at least, there should be an eq optional attribute to [bind_s], and the
last line should be [S.switch ~eq init changes]

[-- Attachment #2: Type: text/html, Size: 1177 bytes --]

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

[Lukasz Stafiniak]

[-- Attachment #1: Type: text/plain, Size: 776 bytes --]

On Fri, Mar 8, 2013 at 10:43 AM, Philippe Veber <philippe.veber@gmail.com>wrote:

> Dear functional-reactive camlers,
>
> In order to change the dependencies between signals dynamically, one can
> use the switch function whose type is:
>
> utop $ React.S.switch;;
> - : ?eq:('a -> 'a -> bool) -> 'a React.signal -> 'a React.signal
> React.event -> 'a React.signal = <fun>
>
> However I often find myself wanting to write signals of signals, and I
> wrote the following definition to cope with them:
>
> val bind_s : 'a React.signal -> ('a -> 'b React.signal) -> 'b


"Bind" is the basic building block of the Froc library:

val bind :
  ?eq:('a -> 'a -> bool) ->
  'b Froc.behavior ->
  ('b -> 'a Froc.behavior) -> 'a Froc.behavior

 I know I'm not answering your question...

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

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

[Philippe Veber]

[-- Attachment #1: Type: text/plain, Size: 992 bytes --]

2013/3/8 Lukasz Stafiniak <lukstafi@gmail.com>

>
>
>
> On Fri, Mar 8, 2013 at 10:43 AM, Philippe Veber <philippe.veber@gmail.com>wrote:
>
>> Dear functional-reactive camlers,
>>
>> In order to change the dependencies between signals dynamically, one can
>> use the switch function whose type is:
>>
>> utop $ React.S.switch;;
>> - : ?eq:('a -> 'a -> bool) -> 'a React.signal -> 'a React.signal
>> React.event -> 'a React.signal = <fun>
>>
>> However I often find myself wanting to write signals of signals, and I
>> wrote the following definition to cope with them:
>>
>> val bind_s : 'a React.signal -> ('a -> 'b React.signal) -> 'b
>
>
> "Bind" is the basic building block of the Froc library:
>
> val bind :
>   ?eq:('a -> 'a -> bool) ->
>   'b Froc.behavior ->
>   ('b -> 'a Froc.behavior) -> 'a Froc.behavior
>
>  I know I'm not answering your question...
>

You do, at least partially:  now I know this style is natural at least in
one FRP library. Too bad it's not the one I use :o).

[-- Attachment #2: Type: text/html, Size: 1977 bytes --]

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

[Daniel Bünzli]

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.  

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

[Daniel Bünzli]

Le vendredi, 8 mars 2013 à 15:21, Daniel Bünzli a écrit :
> But if it didn't make it *may* be due to thorny signal initialization problems.  

Had a quick look [1], nothing that jumps to my mind.  

Or was maybe it was a (not so clever now it seems) way of side stepping the issue of having to define a notion of equality for signals ?  

Well I'll have to look at that more precisely.  

Daniel

P.S. You should replace your use of ( == ) in S.map by S.equal otherwise you'll get potentially incorrect results (too many updates) with imperative dependent signals if your map function also returns constant signals --- unless you think that two constant signals with the same value should not be thought as equal.

[1] https://github.com/dbuenzli/react/blob/master/src/react.ml#L999

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

[Philippe Veber]

[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

>
> P.S. You should replace your use of ( == ) in S.map by S.equal otherwise
> you'll get potentially incorrect results (too many updates) with imperative
> dependent signals if your map function also returns constant signals ---
> unless you think that two constant signals with the same value should not
> be thought as equal.
>

Thanks, I had overlooked the existence of S.equal.

[-- Attachment #2: Type: text/html, Size: 619 bytes --]

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

[Philippe Veber]

[-- Attachment #1: Type: text/plain, Size: 2178 bytes --]

Hi Daniel and thanks for your detailed answers.


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



>
> 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)).
>
indeed. I may be happy enough with [switch_s]. I just thought that [bind_s]
would be safer to use, as the user never actually builds a signal of
signal, so he/she cannot mess up with the equality function.


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

I also thought, as you mention in your second message that it was a way to
prevent users to build signals of signal, because then it is easy to forget
to set the eq parameter and raise exceptions (which are difficult to track
down). If so then let me stress than bind_s helps a little 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.

Well yes I have a bind_s called in a function used with S.fix. Now I
understand that I live dangerously here.


>
> 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.
>
That'd be very kind of you, thanks a lot already for taking time to make
that matter clear to me!

cheers,
ph.

P.S.

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.
>
This is most certainly far beyond my abilities, but I'll definitely have a
look at it!

[-- Attachment #2: Type: text/html, Size: 3172 bytes --]