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 q1ED1314023762 for ; Tue, 14 Feb 2012 14:01:05 +0100 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AogCAAJaOk9KN1ZKnGdsb2JhbABEhRSrMAEBAQEBCAsJCRQngXIBAQQBI1YFCwsaAhgOAgI9ChAGG4d0Awaqa4owgS+KKgcCEC4IBAcDBAoEBwUEDAsDAoN9JAIBFQOCIjNjBJp5jR4 X-IronPort-AV: E=Sophos;i="4.73,416,1325458800"; d="scan'208";a="131290779" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail4-smtp-sop.national.inria.fr with ESMTP; 14 Feb 2012 14:01:04 +0100 Received: from heyho.local (95-234.197-178.cust.bluewin.ch [178.197.234.95]) by smtp.webfaction.com (Postfix) with ESMTP id DEC76209EE24; Tue, 14 Feb 2012 07:01:01 -0600 (CST) Date: Tue, 14 Feb 2012 14:00:58 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Adrien Cc: Philippe Veber , caml users Message-ID: In-Reply-To: References: <4EE9238E9F474D96925E5920255FD691@erratique.ch> 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 q1ED1314023762 Subject: Re: [Caml-list] Functional GUI programming: looking for good practices Le mardi, 14 février 2012 à 12:52, Adrien a écrit : > Quite often, doing so does not make a lot of sense. > Suppose that you have a signal A. An external event triggers an update which > will create A1. But during that update, you trigger another update which > will create A2. Now, how does your signal change? Is A2 going to be the next > value of A or is will it be A1? Yes it doesn't make any sense at all. An update cycle is made under a synchrony hypothesis, everything therein happens simultaneously, at the same time t. The semantics of a signal (resp. event) [1] is a *function* from time to a value (resp. optional value). There's no way a signal (resp. event) can have two different values for the same time t, this should raise a red flag. Besides by definition two primitive events cannot (should not, since the system cannot enforce it) occur at the same time t [2]. When in doubt, it helps to get back to the semantics to see if your interfacing mechanic to react actually respects FRP's semantics. And if it doesn't and you can't fix it, I wouldn't try to use react for the problem. Best, Daniel P.S. to Philipe I'm not exactly sure what you problem is. But if you are trying to define a signal that somehow depends on itself, make sure you did understand the {E,S}.fix combinators [3]. I'm sure I had to use it once or twice to define the (very primitive) UI of the breakout.ml example from the distribution. [1] http://erratique.ch/software/react/doc/React#sem [2] http://erratique.ch/software/react/doc/React#simultaneity [3] http://erratique.ch/software/react/doc/React#recursion