From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id BD3B37F30D for ; Fri, 8 Mar 2013 15:22:15 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=pra; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of daniel.buenzli@erratique.ch) identity=mailfrom; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="daniel.buenzli@erratique.ch"; x-conformance=sidf_compatible Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@smtp.webfaction.com) identity=helo; client-ip=74.55.86.74; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="daniel.buenzli@erratique.ch"; x-sender="postmaster@smtp.webfaction.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar4BALvyOVFKN1ZKkGdsb2JhbABDhQeDGrwrgW8OAQEBAQkJFBQogiwBAQQBIwRSBQsLGgImAgJHEAYbiAUGBKkMkXyBI402MweCLTJhA5w5E44E X-IPAS-Result: Ar4BALvyOVFKN1ZKkGdsb2JhbABDhQeDGrwrgW8OAQEBAQkJFBQogiwBAQQBIwRSBQsLGgImAgJHEAYbiAUGBKkMkXyBI402MweCLTJhA5w5E44E X-IronPort-AV: E=Sophos;i="4.84,808,1355094000"; d="scan'208";a="6119811" Received: from mail6.webfaction.com (HELO smtp.webfaction.com) ([74.55.86.74]) by mail2-smtp-roc.national.inria.fr with ESMTP; 08 Mar 2013 15:22:15 +0100 Received: from [172.20.10.2] (87-232.197-178.cust.bluewin.ch [178.197.232.87]) by smtp.webfaction.com (Postfix) with ESMTP id 1A74420AB242; Fri, 8 Mar 2013 14:22:10 +0000 (UTC) Date: Fri, 8 Mar 2013 15:21:51 +0100 From: =?utf-8?Q?Daniel_B=C3=BCnzli?= To: Philippe Veber Cc: caml users Message-ID: In-Reply-To: References: X-Mailer: sparrow 1.6.4 (build 1178) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Subject: Re: [Caml-list] Signals of signals in react Hello, Le vendredi, 8 mars 2013 =C3=A0 10:43, Philippe Veber a =C3=A9crit :=20=20 > val bind_s : 'a React.signal -> ('a -> 'b React.signal) -> 'b React.signal I guess the semantics you want is : [bind_s s sf]_t =3D [sf [s]_t]_t. Well that doesn't seem unreasonable. I remember having pondered a lot about= which switching combinators to take in the interface and I'm sure I must h= ave considered at least : switch_s : 'a signal signal -> 'a signal=20=20 (* [switch ss]_t =3D [[ss]_t]_t *) that would allow for a very easy implementation of bind (switch_s (S.map f = s)).=20=20=20 But if it didn't make it *may* be due to thorny signal initialization probl= ems. If you look the signature of the current switch it's a way to force yo= u to have to give an initial value. But a signal, once created, is supposed= to have a value at each point in time, well with dynamic switching there a= re fine points to consider that I don't have in my head right now.=20=20 > let bind_s s f =3D=20=20 > let s' =3D S.map ~eq:( =3D=3D ) f s in > let init =3D S.value s' > and changes =3D S.changes s' in > S.switch init changes >=20=20 > So far it worked as I thought it would, but still I'm not really confiden= t this is a safe use of signals. Does anyone see a potential pitfall here? As a rule of thumb using S.value is never safe if you are inside an update = cycle, this means that you may get problems if you use bind_s during an upd= ate cycle itself. Now sometimes it may be hard to find a counter example, a= s it may be hidden in the messy mechanisms needed to support fixed point co= mbinators and dynamic signal creation. I guess the problem would likely ar= ise if s is itself created during the update cycle, in some cases it could = not be initialized yet.=20=20 It's a little bit irritating as what you want seems really sound to me, but= I'm afraid you cannot implement it with the current interface without prov= iding an initial value yourself.=20=20 I don't have the time to investigate right now but I'll surely get back to = it later to give you a definitive answer.=20=20 Daniel =20=20 P.S.=20=20 If switch_s can be implemented without problems I'll gladly incorporate it = into as *the* S.switch, since the current S.switch would then just be: sswitch (S.hold s es) If you are interested you may want to have a look at react's imperative hel= l to see if it seems workable. Especially by considering/transforming the c= urrent S.switch combinator.=20=20