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 mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 47FF3BC37 for ; Thu, 10 Dec 2009 04:38:06 +0100 (CET) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEBAF/8H0vRVdvdkGdsb2JhbACEJZcAPwEBAQEJCQwHEwOpE4FZhU6IaQECAwWBKoIqUwSCfIgq X-IronPort-AV: E=Sophos;i="4.47,372,1257116400"; d="scan'208";a="39600771" Received: from mail-ew0-f221.google.com ([209.85.219.221]) by mail3-smtp-sop.national.inria.fr with ESMTP; 10 Dec 2009 04:38:05 +0100 Received: by ewy21 with SMTP id 21so1466794ewy.22 for ; Wed, 09 Dec 2009 19:38:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=SI/OBbZ6ASWruL4nZ1OSByMqIHBmqTEhpTL6QQU1/5o=; b=OwzsOpDEZVSK/YZgtdMPvXfU1Gp3OHDe7Dc0NBwgSQ8bQnb1dqTL1AOfMItt7AuWXS CJ+ZkuZ35jLt2DupY7ej6szZ9B+y06PCkpdqlBt5a3FILatdQynHTbKgvSwzFUAnAx7o KRVGkCkCVdii6gDkS6P9Q0IPde+bz0CGir5e4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=WrfKxBCW0VrZdMqXWI42z2Tfj9awA+xupFVozxpwndzFsvwRLyGe7e+sX53EAB4QEB f9q8EtEApNwbNzoetEQ2IGsGM5hWhE9kDQqorSxFHpq5vYNtfiZbyKfmWtuby+pQty41 5ztFrZtWkoHfLaR0vdnozoU0D584QOvm6mVaY= MIME-Version: 1.0 Sender: daniel.c.buenzli@gmail.com Received: by 10.213.43.197 with SMTP id x5mr10340361ebe.72.1260416284895; Wed, 09 Dec 2009 19:38:04 -0800 (PST) In-Reply-To: <4B1FE5E0.2020506@citycable.ch> References: <4B1F0E3A.3040907@citycable.ch> <91a3da520912082353m5c75f307j6f9542877d84841f@mail.gmail.com> <20091209112316.GA15607@annexia.org> <4B1FE5E0.2020506@citycable.ch> Date: Thu, 10 Dec 2009 11:38:04 +0800 X-Google-Sender-Auth: d5d6f3cb2f40db14 Message-ID: <91a3da520912091938l4f81209ard2be25731ba9f593@mail.gmail.com> Subject: Re: [Caml-list] Re: Recursion on React.events. From: =?UTF-8?Q?Daniel_B=C3=BCnzli?= To: guillaume.yziquel@citycable.ch Cc: Richard Jones , OCaml List Content-Type: text/plain; charset=UTF-8 X-Spam: no; 0.00; recursion:01 buenzli:01 daniel's:01 low-level:01 implements:01 semantics:01 low-level:01 abstraction:01 parser:01 parser:01 abstraction:01 threads:01 threads:01 caml-list:01 primitives:01 > 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