Re: [Caml-list] Re: Recursion on React.events.

[Guillaume Yziquel <guillaume.yziquel@citycable.ch>]

Daniel Bünzli a écrit :
>> Unfortunately, it seems to me that Daniel's module is fairly low-level in
>> the sense that it implements the bare mechanics and semantics of FRP.
> 
> Yes, react is low-level and will remain. The rationale is that I want
> the client of the module to be able to decide the application
> structure. This makes react more flexible and easier to embed were you
> need to.

That's perfect. You should perhaps think of creating a Convenience 
submodule where some useful patterns could be thrown in by third 
parties. After having been 'moderated' by you, of course.

> I could have decided that react has a global queue and every primitive
> update has to go through that queue (for the client this would have
> simplified the feedback of primitives into the reactive system). But
> then the module is not thread-safe and you get compositional problems
> when you want to integrate two libraries
> using react in a threaded environment. I could have decided that the
> reactive engine runs on its own thread but maybe you don't want to use
> threads etc.

No no no! Indeed, it's much better as it is today.

> For example with the current design two part of a program may use
> react as they wish internally without any problem even on different
> threads as long as their signals and events don't interact. With the
> current structure it also means that a library designer using react
> has to make sure the way he design should play nice with other part
> defining their own primitive events.

Yes, indeed. But that's also the tricky part where some useful 
constructs would indeed be... useful.

> So yes it means a little bit more work and understanding for the
> client. But I think it pays to have a reactive engine that doesn't
> impose too much on you. The client always knows better the abstraction
> he's after and the setting in which it has to implement it. But if a
> consistent and compositional pattern of use emerges I'm always willing
> to support it directly in the library.

All to true. But that would be the purpose of a Convenience submodule 
(once you get constructive feedback).

>> For example, make a parser of the Asterisk Manager Interface
>> with React around OCamlNet's Uq_engine module proved to be quite tricky, in
>> a similar way as the issue that started this thread (here, I had no event,
>> but in the Asterisk parser, I had doubled events, and I solved it in a very
>> very ugly way).
> 
> Note that as we discussed I highly suspect you used the wrong
> abstraction there (events vs. signals).

Very possibly. I will have to get back to it one day to make it clean. 
Now that I know where to find the documentation for E.fix, it's only a 
question of *cough* time *cough*.

>> It's true that I may not completely understand how React works, as Daniel stated it before (a bit better now)
> 
> Btw this was not intended to be offensive. It was to say the reactive
> engine has a well defined way to work that should be respected (the
> update cycle) so don't try to trick around too much with it when you
> cannot achieve want you want.

Yes. It's also here where I worry about a few things concerning Lwt:

In Lwt, you have a monadic way to do context switches for multithreading 
withing a single real thread. So if you use Lwt inside the update cycle, 
you could well jump out of the update cycle with a Lwt context switch. 
As long as you do not encounter a Lwt construct within definition of 
signals and events, you can be pretty sure that the update cycle will go 
through to its end without using Lwt inside an event/signal. But at the 
same time, it seems that the monadic way Lwt is built avoids us such 
problems. But I may be mistaken.

This issue can be interesting and important.

'a Lwt.t represents the type of a promise of something of type 'a, 
essentially. So you could use in parallel processing: Imagine that 'a 
Remote.t represents the type of something computed on a remote computer. 
You could use type 'a Remote.t Lwt.t to represent the promise of a 
computation of 'a done on a remote computer. It therefore could make 
sense to have a single computer in charge of receiving React.events with 
a unique update cycle, and transfering the computation to other 
computers, represented as non-primary 'a Remote.t Lwt.t React.signal-s. 
Using S.fix, one could also feed events to such a signal, using S.fix to 
bind the t-dt Lwt.t value of the signal to the t value of the same signal.

That may seem quite involved, but conceptually, it could be a clean way 
to type rather efficiently parallel computations. When binding such 
signals, you could also implement code mobility, marshaling features to 
take care of the work load of multiple computers.

So the compatibility of Lwt and React seems to me a worthwile question 
if one wants to use OCaml for high availability, reactive, parallel 
computations. And in this context, making E/S.switch easy to use would 
quite important...

> Best,
> 
> Daniel

All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/