> 1) You need to say something about the dynamic environment in which the
> task runs: is it the environment of the call to make-timer, timer-start!,
> or timer-schedule!?
It should be where the `thunk` is captured. I'm not sure if I understand
what you meant correctly. Could you maybe give me a clear example why
this needs to be clarified?

> 2) I agree that there's no need to separate timer-start! and
> timer-schedule!.  To break the symmetry, rename timer-stop! to
> timer-cancel!, which is more the idea anyway (since it cannot be
> restarted).
You mean `make-timer` and `timer-start!`? `timer-cancel!` sounds good,
I'll change it.

> 3) Rather than talking about time objects, simply talk about integers,
> and then say that implementations may extend the appropriate arguments
> to implementation-specified objects.
The reason why I've added the time object is that it can handle nano
second. If users want to make smaller unit of period, then at least the
SRFI can handle it. Or it might be better to let the integer represents
nano second instead of milli second. Any opinion?

> 4) Timer-{remove!,exists} would be clearer as timer-task-{remove!,exists},
> since they affect only one of many possible tasks.
Sounds good, I'll change it.

> 5) Better not to say that id is an integer, but leave it as an unspecified
> and possibly disjoint type.
The idea behind this is that if other process (not thread) want to stop
a task, then it needs to be a readable datum. Well, it might be users'
responsibility to handle it properly. How about adding timer type which
contains its id and modification procedures should accept both timer
task itself and id to modify timer?

> 6) Need to say something about what can be done from a task, such as
> cancel other tasks on the same timer, change its own scheduling, etc.
> This affects how much safety an implementation needs.
Good point. A task should be able to cancel other tasks but should not
be able to cancel/reschedule itself. I'll add it.

> 7) Are tasks potentially run concurrently, or always sequentially?
> Or concurrently on different timers but sequentially on the same timer?
It doesn't have to be sequentially. If the same task is scheduled on
different
timer, then it should be run concurrently. But timer doesn't have to
guarantee the task's atomicity. I'll add it.

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