From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail1-relais-roc.national.inria.fr (mail1-relais-roc.national.inria.fr [192.134.164.82]) by yquem.inria.fr (Postfix) with ESMTP id D2FB6BC37 for ; Thu, 10 Dec 2009 23:23:54 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AoADAFcDIUtV2gB4h2dsb2JhbACEG5RRglABAQEKCwgHFatNkBWBL4IqUgSDGIYD X-IronPort-AV: E=Sophos;i="4.47,377,1257116400"; d="scan'208";a="41780373" Received: from emailfrontal1.citycable.ch ([85.218.0.120]) by mail1-smtp-roc.national.inria.fr with SMTP; 10 Dec 2009 23:23:54 +0100 Received: from [192.168.0.12] (unknown [85.218.92.99]) (Authenticated sender: guillaume.yziquel@citycable.ch) by emailfrontal1.citycable.ch (Postfix) with ESMTPA id F10AA12C1A0; Thu, 10 Dec 2009 23:23:52 +0100 (CET) Message-ID: <4B21750F.9060707@citycable.ch> Date: Thu, 10 Dec 2009 23:24:15 +0100 From: Guillaume Yziquel Reply-To: guillaume.yziquel@citycable.ch User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090707) MIME-Version: 1.0 To: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= Cc: Richard Jones , OCaml List Subject: Re: [Caml-list] Re: Recursion on React.events. References: <4B1F0E3A.3040907@citycable.ch> <91a3da520912082353m5c75f307j6f9542877d84841f@mail.gmail.com> <20091209112316.GA15607@annexia.org> <4B1FE5E0.2020506@citycable.ch> <91a3da520912091938l4f81209ard2be25731ba9f593@mail.gmail.com> In-Reply-To: <91a3da520912091938l4f81209ard2be25731ba9f593@mail.gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Spam: no; 0.00; guillaume:01 guillaume:01 recursion:01 daniel's:01 low-level:01 implements:01 semantics:01 low-level:01 submodule:01 abstraction:01 submodule:01 parser:01 parser:01 abstraction:01 monadic:01 Daniel B=C3=BCnzli a =C3=A9crit : >> 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. >=20 > 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=20 submodule where some useful patterns could be thrown in by third=20 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=20 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=20 (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 trick= y, in >> a similar way as the issue that started this thread (here, I had no ev= ent, >> but in the Asterisk parser, I had doubled events, and I solved it in a= very >> very ugly way). >=20 > 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.=20 Now that I know where to find the documentation for E.fix, it's only a=20 question of *cough* time *cough*. >> It's true that I may not completely understand how React works, as Dan= iel stated it before (a bit better now) >=20 > 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=20 withing a single real thread. So if you use Lwt inside the update cycle,=20 you could well jump out of the update cycle with a Lwt context switch.=20 As long as you do not encounter a Lwt construct within definition of=20 signals and events, you can be pretty sure that the update cycle will go=20 through to its end without using Lwt inside an event/signal. But at the=20 same time, it seems that the monadic way Lwt is built avoids us such=20 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,=20 essentially. So you could use in parallel processing: Imagine that 'a=20 Remote.t represents the type of something computed on a remote computer.=20 You could use type 'a Remote.t Lwt.t to represent the promise of a=20 computation of 'a done on a remote computer. It therefore could make=20 sense to have a single computer in charge of receiving React.events with=20 a unique update cycle, and transfering the computation to other=20 computers, represented as non-primary 'a Remote.t Lwt.t React.signal-s.=20 Using S.fix, one could also feed events to such a signal, using S.fix to=20 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=20 to type rather efficiently parallel computations. When binding such=20 signals, you could also implement code mobility, marshaling features to=20 take care of the work load of multiple computers. So the compatibility of Lwt and React seems to me a worthwile question=20 if one wants to use OCaml for high availability, reactive, parallel=20 computations. And in this context, making E/S.switch easy to use would=20 quite important... > Best, >=20 > Daniel All the best, --=20 Guillaume Yziquel http://yziquel.homelinux.org/