From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 E4F097F30A for ; Fri, 8 Mar 2013 23:18:05 +0100 (CET) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of philippe.veber@gmail.com) identity=pra; client-ip=74.125.82.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of philippe.veber@gmail.com designates 74.125.82.176 as permitted sender) identity=mailfrom; client-ip=74.125.82.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="philippe.veber@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-we0-f176.google.com) identity=helo; client-ip=74.125.82.176; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="philippe.veber@gmail.com"; x-sender="postmaster@mail-we0-f176.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At4BAAFjOlFKfVKwiGdsb2JhbABDxE+BVQgWDgEBAQoJFBQEJIIsAQEEAScZARsdAQMBCwYFCzsiAREBBQEcBhuHeAEDCQadaowygnuEOwoZJw1ZiHwBBQyPAAeDQAOWU48QFimELg X-IPAS-Result: At4BAAFjOlFKfVKwiGdsb2JhbABDxE+BVQgWDgEBAQoJFBQEJIIsAQEEAScZARsdAQMBCwYFCzsiAREBBQEcBhuHeAEDCQadaowygnuEOwoZJw1ZiHwBBQyPAAeDQAOWU48QFimELg X-IronPort-AV: E=Sophos;i="4.84,810,1355094000"; d="scan'208";a="6175824" Received: from mail-we0-f176.google.com ([74.125.82.176]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 08 Mar 2013 23:18:05 +0100 Received: by mail-we0-f176.google.com with SMTP id s43so1620947wey.35 for ; Fri, 08 Mar 2013 14:18:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:mime-version:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=Qpyzt0VccY89bFvWpFLwv3uwC9i8zbtTBL/jYUooSGA=; b=XaMZs87YjGg+zVZjAI6k5CiTIY12SAlt0ETmRHR3YYGJK9xTamq5KOfB1s1SUr/0MN m+NSaChvma1CfVC/9cvFenSvSmgcWLis8pzrZqcqzby5+z3usCX8/Ki2LA1RBdAqlBB+ tNjUUwCpSiIt4xsb00m5Q3wDrgHHh48OJoF0/d55JJDRfRYsVeRPJ8GtOdYCd/IYtewy uBDVl/Cgo08uya8CkEaYvTR4IwQC19/KrHz4MeWafnoeh8rH73R8vXXBxWJkfmbjpWb4 ix2oF/YQv9QIw730KiD9VII4+dtwOExdXjzya51fLveIA0Z6mH8tYr46tBhq+taqv3Nu Mu2g== X-Received: by 10.194.95.198 with SMTP id dm6mr7105870wjb.6.1362781085495; Fri, 08 Mar 2013 14:18:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.194.87.230 with HTTP; Fri, 8 Mar 2013 14:17:45 -0800 (PST) In-Reply-To: References: From: Philippe Veber Date: Fri, 8 Mar 2013 23:17:45 +0100 Message-ID: To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: caml users Content-Type: multipart/alternative; boundary=047d7bb03a5081f7af04d77132f1 X-Validation-by: philippe.veber@gmail.com Subject: Re: [Caml-list] Signals of signals in react --047d7bb03a5081f7af04d77132f1 Content-Type: text/plain; charset=ISO-8859-1 Hi Daniel and thanks for your detailed answers. I guess the semantics you want is : [bind_s s sf]_t = [sf [s]_t]_t. > that's right. > > 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 have considered at least : > > switch_s : 'a signal signal -> 'a signal > (* [switch ss]_t = [[ss]_t]_t *) > > that would allow for a very easy implementation of bind (switch_s (S.map f > s)). > indeed. I may be happy enough with [switch_s]. I just thought that [bind_s] would be safer to use, as the user never actually builds a signal of signal, so he/she cannot mess up with the equality function. > > But if it didn't make it *may* be due to thorny signal initialization > problems. If you look the signature of the current switch it's a way to > force you to have to give an initial value. I also thought, as you mention in your second message that it was a way to prevent users to build signals of signal, because then it is easy to forget to set the eq parameter and raise exceptions (which are difficult to track down). If so then let me stress than bind_s helps a little 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 > update cycle itself. Well yes I have a bind_s called in a function used with S.fix. Now I understand that I live dangerously here. > > 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 > providing an initial value yourself. > > 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. > That'd be very kind of you, thanks a lot already for taking time to make that matter clear to me! cheers, ph. P.S. If you are interested you may want to have a look at react's imperative > hell to see if it seems workable. Especially by considering/transforming > the current S.switch combinator. > This is most certainly far beyond my abilities, but I'll definitely have a look at it! --047d7bb03a5081f7af04d77132f1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Daniel and thanks for your detailed answers.


I guess the semantics you want is : [bind_s s sf]_t =3D [sf [s]_t]_t.
that's right.

=A0

Well that doesn't seem unreasonable. I remember having pondered a lot a= bout which switching combinators to take in the interface and I'm sure = I must have considered at least :

switch_s : 'a signal signal -> 'a signal
(* [switch ss]_t =3D [[ss]_t]_t *)

that would allow for a very easy implementation of bind (switch_s (S.map f = s)).
indeed. I may be happy enough with [switch_s]. I = just thought that [bind_s] would be safer to use, as the user never actuall= y builds a signal of signal, so he/she cannot mess up with the equality fun= ction.
=A0

But if it didn't make it *may* be due to thorny signal initialization p= roblems. If you look the signature of the current switch it's a way to = force you to have to give an initial value.
I also though= t, as you mention in your second message that it was a way to prevent users= to build signals of signal, because then it is easy to forget to set the e= q parameter and raise exceptions (which are difficult to track down). If so= then let me stress than bind_s helps a little here.
=A0


As a rule of thumb usin= g 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 update cycle itself.
Well yes I have a bind_s called in a function used with S.fix. Now I u= nderstand that I live dangerously here.
=A0

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 with= out providing an initial value yourself.

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.
That= 'd be very kind of you, thanks a lot already for taking time to make th= at matter clear to me!

cheers,
ph.
=A0
P.S.

If you are interested you may want to have a look at react's imperative= hell to see if it seems workable. Especially by considering/transforming t= he current S.switch combinator.
This is most certainly= far beyond my abilities, but I'll definitely have a look at it!

--047d7bb03a5081f7af04d77132f1--