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.
Takashi Kato scripsit:
> Is SRFI-120 good enough to be final? If you have any comment, please
> speak up. If I didn't here anything in a week, I would like to finalise
> it.
Sorry for not commenting earlier.
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!?
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).
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.
4) Timer-{remove!,exists} would be clearer as timer-task-{remove!,exists},
since they affect only one of many possible tasks.
5) Better not to say that id is an integer, but leave it as an unspecified
and possibly disjoint type.
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.
7) Are tasks potentially run concurrently, or always sequentially?
Or concurrently on different timers but sequentially on the same timer?
--
John Cowan http://www.ccil.org/~cowan cowan@xxxxxxxx
Statistics don't help a great deal in making important decisions.
Most people have more than the average number of feet, but I'm not about
to start a company selling shoes in threes. --Ross Gardler