> That sounds like the right idea.  Because the thunks run concurrently
> with the main Scheme program, they have to capture the dynamic
> environment so that, for example, if the main program changes the
> value of current-output, the thunk isn't affected.
Ah, ok now I understand. I'll add it.

> Well, a simple approach would be to use a pair of fixnums (a . b)
> such that the value is a * 10 ^ -b, so (30 . 9) would mean 30
> nanoseconds.  Just having a nanosecond count is problematic,
> because 2^30 ns is only a little more than 1 second.
The period can also be bigger amount such as hour. So I think it's
more intuitive if we can specify its unit.

> Another thing to explain is what happens if a task is still running
> when it is rescheduled.  I assume that it just goes on running,
> but the SRFI should say so.
Good point. I'll add it.

> Here's an idea to simplify things: have only one task per timer, and if
> you want to execute more than one thunk, have more than one timer.
> Right now it seems to make no difference if you have many tasks on a
> timer or many timers, but using the second approach allows you
> to simplify the API to (make-timer thunk when [period]), timer?,
> timer-cancel!, and (timer-reschedule! when [period]).
This is a good idea if the SRFI can specify the cost of timer creation
really cheap. However if a timer creates a thread like reference
implementation, then the cost of thread creation might be expensive.

_/_/
Takashi Kato
E-mail: xxxxxx@ymail.com