From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail4-relais-sop.national.inria.fr (mail4-relais-sop.national.inria.fr [192.134.164.105]) by walapai.inria.fr (8.13.6/8.13.6) with ESMTP id q3IBiYU7030425 for ; Wed, 18 Apr 2012 13:44:35 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjsDAEyojk/Y5v4vmGdsb2JhbABEgxyCSpgTkCmDGiIBAQEBAQYLDQcUJ4IJAQEEASMECwEFQAEFCwsYAgIFAxMLAgIJAwIBAgFFEwgBAYgGBAGmaJMTgS+MFIINgRgEiFqNFYVzjT0 X-IronPort-AV: E=Sophos;i="4.75,441,1330902000"; d="scan'208";a="140648064" Received: from amout07.alpha-mail.net ([216.230.254.47]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Apr 2012 13:44:30 +0200 Received: from webarc04.alpha-mail.jp (webarc04 [216.230.254.84]) by amout07.alpha-mail.net with ESMTP id q3IBiQBV008365; Wed, 18 Apr 2012 20:44:26 +0900 X-Virus-Scanned: amavisd-new at Alpha-Mail Out Received: from ltsub01.alpha-mail.net (ltsub01 [216.230.254.29]) by webarc04.alpha-mail.jp (Postfix) with ESMTP id E3D561C080D3; Wed, 18 Apr 2012 20:44:19 +0900 (JST) Received: from [192.168.0.110] (196.62.205.61.west.global.crust-r.net [61.205.62.196]) by ltsub01.alpha-mail.net (Alpha-mail) with ESMTP id 6E3C33B8098; Wed, 18 Apr 2012 20:44:25 +0900 (JST) Message-ID: <4F8EA91C.3060001@itpl.co.jp> Date: Wed, 18 Apr 2012 20:44:28 +0900 From: Satoshi Ogasawara User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:11.0) Gecko/20120327 Thunderbird/11.0.1 MIME-Version: 1.0 To: daniel.buenzli@erratique.ch Cc: caml-list@inria.fr References: <4F8D9D0E.1040007@itpl.co.jp> <4F8E1FF4.5070702@itpl.co.jp> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Caml-list] [ANN] PEC ver. 1.1 Hello, Thank you very much for your prompt reply. (2012/04/18 16:36), Daniel Bünzli wrote: > 1) Thread-safety and compositionality. React has no global data structure. I'm sorry about my misunderstanding that React has a global structure. > 2) Semantic issues. As soon as primitive events are triggered by other primitive events you run into the problem of multiple occurences of the same event during an update cycle. Now given the synchrony hypothesis of update cycles (an update cycle is instantaneous), this is a violation of the semantics of events (an event has at most one occurence at any given time t). And then people ask you if you can somehow manage the order of updates in an update cycle and then you are not doing FRP anymore, you are doing RP. By loosing the F you also loose compositionality and the equational reasoning tools provided by the denotational semantics of events. I see that React is implemented with intend to keep good semantics and able to realize same functions as PEC. But PEC dose not violate good semantics either. PEC treats only one event at any given time t. Please see blow code. module E = Pec.Event.Make (Pec.EventQueue.DefaultQueueM) (Pec.EventQueue.DefaultQueueI) open Printf let _ = let e, sender = E.make () in let e' = E.map (fun x -> sender 2; x + 1) e in (* during update cycle, send 2. *) let _ = E.subscribe (printf "e=%d\n") e in let _ = E.subscribe (printf "e'=%d\n") e' in sender 1; ignore (E.run ()); (* run one event *) printf "---\n"; ignore (E.run ()); (* run one event *) printf "end\n" This program outputs: e=1 e'=2 --- e=2 e'=3 end The function (fun x -> sender 2; x + 1) is not purely functional. I see that violates a part of good semantics and composability. But there is no problem of multiple occurrences of the same event in one update cycle. To write event driven systems such like GUI sometimes needs a event-event chain without real-user actions. Sending events during update cycle is something unavoidable. > Regarding the absence of Weak usage I'm curious in how you manage the garbage collections of events that depend on others. Yes, weak-pointer-less implementation is one of my purpose. The key point is that dependency of events are represented by nested variants. Best Regards, Ogasawara