Version franaise
Home About Download Resources Contact us

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Recursion on
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2009-12-09 (04:25)
From: Daniel_Bünzli <daniel.buenzli@e...>
Subject: Re: Recursion on
>> let rec regular_schedule start_time period =
>>  React.E.switch React.E.never begin
>>    begin fun () -> regular_schedule (Calendar.add ( ())
>> period) period end
>>    begin schedule start_time end
>>  end

Look at the semantic definition of E.switch in the documentation. When
a tick happens the whole switch switches instantaneously to the event
for the new tick returned by regular_schedule which will happen in
now+period. You never see ticks because as soon a tick happen you
replace the event that should "show" the tick by "showing" the next

Anyway don't do any recursive tricks unless you really know what you
are doing (which you don't seem). You are asking for trouble (infinite
loops and puzzling behaviour more precisely). The ONLY right way to
define recursive events and signals is to use the fixed point
operators. So in your case something like this should work :

let regular_schedule start_time period =
  let define tick = (* tick is the value of tick' dt times ago *)
    let tick' =
      let reschedule () = Calendar.add ( ()) period in
      React.E.switch (schedule start_time) ( reschedule tick)
    tick', tick'
  E.fix define

So basically after a tick' happens, tick will immediatly (but not
instantaneously) happen and reschedule a new tick' occurence.

Note that in general I would avoid what you are doing altoghether by
providing regular_schedule as a primitive as you do for schedule. If
you are using too much ugly side effects and tricks in your event
definitions then you loose all the benefits of frp.



P.S. You may want to have a look at rtime :