caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Guillaume Yziquel <guillaume.yziquel@citycable.ch>
To: "OCaml List" <caml-list@inria.fr>,
	"Daniel Bünzli" <daniel.buenzli@erratique.ch>
Subject: Re: Recursion on React.events.
Date: Wed, 09 Dec 2009 04:22:43 +0100	[thread overview]
Message-ID: <4B1F1803.9010203@citycable.ch> (raw)
In-Reply-To: <4B1F0E3A.3040907@citycable.ch>

Guillaume Yziquel a écrit :
> Hello.
> 
> I've been dabbling with recursive definition of React events.
> 
> Suppose I have a function called schedule of type
> 
>     val schedule : Calendar.t -> unit React.event
> 
> which throws out an event at the specified time or date.
> 
> I've been trying to create a regular_schedule function that throws 
> events at a regular pace. Daniel Bünzli's module is great, but sometimes 
> a bit rough to get by, specifically on examples such as this one.
> 
> So I came up with a recursive definition of such a React.event:
> 
>> let rec regular_schedule start_time period =
>>   React.E.switch React.E.never begin React.E.map
>>     begin fun () -> regular_schedule (Calendar.add (Calendar.now ()) 
>> period) period end
>>     begin schedule start_time end
>>   end
> 
> First question:
> 
> It almost works, in the sense that if you insert a print_endline after 
> the fun (), well, it indeeds prints stuff on stdin at the specified 
> pace. However, somehow, the event as a whole behaves as React.E.never. 
> So it doesn't work. I guess it has to do with the way React.switch works 
> synchronously, but I really do not get it.

OK. The following piece of code works out, but it seems to me that using 
a React.E.select in this position is a rather ugly hack.

let rec regular_schedule start period =
   let waiting_for = schedule start in
   React.E.switch React.E.never begin React.E.map
     begin fun () -> React.E.select [waiting_for; regular_schedule
       (Calendar.add (Calendar.now ()) period) period]
     end waiting_for
   end


> Second question:
> 
> Is there somehow a notion of 'tail recursion' for such constructs?

I gave some thought to it, and it seems quite plausible that what is 
done in the first place is analoguous to tail recursion. And that using 
React.E.select breaks the tail recursion. Am I offtrack?

> All the best,

-- 
      Guillaume Yziquel
http://yziquel.homelinux.org/


  reply	other threads:[~2009-12-09  3:23 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-09  2:40 Guillaume Yziquel
2009-12-09  3:22 ` Guillaume Yziquel [this message]
2009-12-09  4:25 ` Daniel Bünzli
2009-12-09 18:47   ` Guillaume Yziquel
2009-12-10  8:39     ` Daniel Bünzli
2009-12-09  7:53 ` Daniel Bünzli
2009-12-09 11:23   ` [Caml-list] " Richard Jones
2009-12-09 18:01     ` Guillaume Yziquel
2009-12-10  3:38       ` Daniel Bünzli
2009-12-10 22:24         ` Guillaume Yziquel
2009-12-11 12:16           ` Jérémie Dimino
2009-12-09 18:24   ` Guillaume Yziquel
2009-12-10  8:24     ` Daniel Bünzli
2009-12-10 21:41       ` Guillaume Yziquel
2009-12-11  1:22         ` Daniel Bünzli

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B1F1803.9010203@citycable.ch \
    --to=guillaume.yziquel@citycable.ch \
    --cc=caml-list@inria.fr \
    --cc=daniel.buenzli@erratique.ch \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).