This page is part of the web mail archives of SRFI 120 from before July 7th, 2015. The new archives for SRFI 120 contain all messages, not just those from before July 7th, 2015.
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: ktakashi@xxxxxxxxx