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 q3J8xTjI008514 for ; Thu, 19 Apr 2012 10:59:29 +0200 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUEAPLSj0/Y5v4vmGdsb2JhbAA6CYMcgkmYIJApgxsiAQEBAQEICQ0HFCeCCQEBBAEjBAsBBUABEAsYAgIFAxMLAgIJAwIBAgFFBg0BBwEBiAYEAadGkyaBL4kyhDyBGASIWo0VhXONPQ X-IronPort-AV: E=Sophos;i="4.75,445,1330902000"; d="scan'208";a="140763644" Received: from amout07.alpha-mail.net ([216.230.254.47]) by mail4-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Apr 2012 10:59:23 +0200 Received: from webarc05.alpha-mail.jp (webarc05 [216.230.254.85]) by amout07.alpha-mail.net with ESMTP id q3J8xJsa011341; Thu, 19 Apr 2012 17:59:19 +0900 X-Virus-Scanned: amavisd-new at Alpha-Mail Out Received: from ltsub02.alpha-mail.net (ltsub02 [216.230.254.30]) by webarc05.alpha-mail.jp (Postfix) with ESMTP id 8E717A4807E; Thu, 19 Apr 2012 17:59:15 +0900 (JST) Received: from [192.168.0.110] (196.62.205.61.west.global.crust-r.net [61.205.62.196]) by ltsub02.alpha-mail.net (Alpha-mail) with ESMTP id 0B52F746005A; Thu, 19 Apr 2012 17:59:18 +0900 (JST) Message-ID: <4F8FD3EB.5050307@itpl.co.jp> Date: Thu, 19 Apr 2012 17:59:23 +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: =?UTF-8?B?RGFuaWVsIELDvG56bGk=?= CC: caml-list@inria.fr References: <4F8D9D0E.1040007@itpl.co.jp> <4F8E1FF4.5070702@itpl.co.jp> <4F8EA91C.3060001@itpl.co.jp> <2B372C89CE4F408688B67B090FA5105C@erratique.ch> <4F8EFC34.7080906@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 (2012/04/19 7:32), Daniel Bünzli wrote: > Yes because the semantics of [e] is violated, it has three values at the same time, the current value during the update cycle, the value 1 and the value 2. Now suppose I reason about the semantics of [e] in this program, it has a well-defined outcome *for [e] itself* if I send it a value [v]. However if you now add a new module that uses [e] and does : Thank you for helping me understand with your explanation. If I understand correctly sending [v] to [e] immediately during update cycle are violate the semantics because it cause more than one values on one event at the same time. Using React, let e, sender = E.create () in let e' = E.map (fun x -> Queue.add q (fun () -> sender 1); x + 1) e in let e'' = E.map (fun x -> Queue.add q (fun () -> sender 2); x + 1) e in does this code violate the semantics of events? If so, PEC is also unsound. I'd like to know PEC is unsound or not. > So if I understand correctly you are doing manual memory management via (un)subscribe of the leaves of the dependency tree and instead of having weak "forward" pointers from events to their dependents you have regular "backward" pointers from events to the events they depend on. Once these leaves are subscribed we can follow them backwards to find out what their primitive event set is and understand what needs to be updated along the way. Yes, exactly. >It may be an interesting approach to avoid weak pointers but I'd need more thinking to convince me it can correctly handles all the dark sides of leaks, fixed point definitions, signal initialization and dynamically changing dependency graph. By the way you still need to update the events in the correct order/and or only once to prevent glitches, how do you achieve that ? To prevent glitches, PEC distinct one update cycle to another by time identity. And calculated results are cached for same update cycle. Update order is straight forward. Just follow from leaf to primitive source event. It's not problem because only one primitive value changes at one update cycle. Best Regards, Ogasawara