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

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

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

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.

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.

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.

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

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

Best,

Daniel