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

[Philippe Veber <philippe.veber@gmail.com>]

[-- 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 --]