Takashi Kato scripsit:

> In that sense, should it run in the dynamic environment when timer is
> created?

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.

> Maybe it's better to back to the
> original suggestion on c.l.s which is creating time delta passing time
> unit (e.g. ms, ns) so that at least the SRFI can guarantee smaller unit
> of period. And if it's a mere integer, then it can treat as if it's a
> millisecond delta. Any opinion?

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.

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.

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]).

--
John Cowan          http://www.ccil.org/~cowan        xxxxxx@ccil.org
Consider the matter of Analytic Philosophy.  Dennett and Bennett are well-known.
Dennett rarely or never cites Bennett, so Bennett rarely or never cites Dennett.
There is also one Dummett.  By their works shall ye know them.  However, just as
no trinities have fourth persons (Zeppo Marx notwithstanding), Bummett is hardly
known by his works.  Indeed, Bummett does not exist.  It is part of the function
of this and other e-mail messages, therefore, to do what they can to create him.