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 q3IDRYfI001993 for ; Wed, 18 Apr 2012 15:27:34 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am0CANTAjk9KN1ZKnGdsb2JhbABEhWareQEBAQEBCAsJCRQnggkBAQQBIwRSBQsLGgIYDgICPQoQBhsTh28FBKchkxiBL44hNWMEm0+NQw X-IronPort-AV: E=Sophos;i="4.75,441,1330902000"; d="scan'208";a="140665952" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail4-smtp-sop.national.inria.fr with ESMTP; 18 Apr 2012 15:27:28 +0200 Received: from heyho.local (81-234.197-178.cust.bluewin.ch [178.197.234.81]) by smtp.webfaction.com (Postfix) with ESMTP id AA48E20B0184; Wed, 18 Apr 2012 08:27:26 -0500 (CDT) Date: Wed, 18 Apr 2012 15:27:21 +0200 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Satoshi Ogasawara Cc: caml-list@inria.fr Message-ID: <2B372C89CE4F408688B67B090FA5105C@erratique.ch> In-Reply-To: <4F8EA91C.3060001@itpl.co.jp> References: <4F8D9D0E.1040007@itpl.co.jp> <4F8E1FF4.5070702@itpl.co.jp> <4F8EA91C.3060001@itpl.co.jp> X-Mailer: sparrow 1.5 (build 1043.1) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by walapai.inria.fr id q3IDRYfI001993 Subject: Re: [Caml-list] [ANN] PEC ver. 1.1 Le mercredi, 18 avril 2012 à 13:44, Satoshi Ogasawara a écrit : > But PEC dose not violate good semantics either. PEC treats only one event at any > given time t. Please see blow code. I don't think your code shows the problem I'm talking about. > 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. *) Here add : let e'' = E.map (fun x -> sender 3; x + 1) e in and now what should the value of e be in the next update cycle ? All the options you have (keep only the first call to sender, keep only the last call to sender, keep both and execute one after the other) break the functional and compositional nature of FRP because it violates the semantics of events. > 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. I don't have enough experience to assert that's really the case. However if that's needed I suspect that the way to resolve conflicts that break the semantics, should they arise, is actually very specific to the problem domain and shouldn't rely on anything related to the order of updates during the update cycle. The only thing I'm saying here is that your first message made it sound like PEC solved a problem of React ("You can send a value to event during update cycle."). It's not a problem of React it's a problem of interfacing FRP with your application domain. And React can perfectly be adapted to use the same unsound solution that PEC seems to use by adding the sender calls in a thunk queue and dequeing after the end of the update cycle. > Yes, weak-pointer-less implementation is one of my purpose. The key point is > that dependency of events are represented by nested variants. That doesn't really answer my question (or at least I don't understand what it means). Best, Daniel