>> 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?
>
> I see now that it has to be at timer-schedule!, but you should still
> say that the thunk runs in the dynamic environment of the call to
> timer-schedule!
Maybe I'm misunderstanding but in that case, should it create dynamic
environments for each `timer-schedule!` call? I think that's a bit odd.
All tasks in the same timer should run in the same dynamic environment.
In that sense, should it run in the dynamic environment when timer is
created?

>> 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?
>
> I think milliseconds is fine.  I just don't want an explicit dependency
> on SRFI 18/19 here.  So integers or implementation-defined things,
> which could be SRFI 19 time objects or something else.
There was a discussion on c.l.s one of which was about the there might
be better to have more precise control.
cf. https://groups.google.com/forum/#!topic/comp.lang.scheme/myobm6h4l6s

I understand avoiding explicit dependency and I do believe milliseconds
is fine in most of the cases. However accepting
implementation-dependent thing makes the program less portable (even
time object would be de-facto). 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?

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