For the second one: I didn’t even think about how it should be treated, to be honest. I would put ‘it is an error if the given task id is not associated to the given timer or the task is already executed and not scheduled anymore’ or something similar. So that implementations can choose appropriate behaviour for this error situation.

Cheers,

Takashi

Hi, Takashi.  Would you please review Shiro's comments below?

Thanks.

---------- Forwarded message ---------
From: Shiro Kawai <xxxxxx@gmail.com>
Date: Fri, May 7, 2021 at 2:49 AM
Subject: Reference implementation fix, and suggested post-finalization fix
To: <xxxxxx@srfi.schemers.org>

I sent a PR to fix a trivial bug in the reference implementation.

https://github.com/scheme-requests-for-implementation/srfi-120/pull/1

Other than that, I noticed a couple of confusing/missing wordings in the srfi text.  One is trivial, another may be controversial.

1. timer-schedule! says "The procedure returns timer id which is a readable datum such as an integer."

The id here is actually associated to a task, rather than a timer.  "Timer id" sounds something unique for each timer.  I think it is just an overlook and making it "task id" makes it less confusing.

(We could also change references to "id" in other description to "task-id", if it is possible).

2. I noticed that there's no mention what happens in timer-reschedule! if the timer doesn't have a task associated to the given id.  So it should be interpreted as implementation dependent.  The reference implementation simply ignores such a task.

It would be nice, though, if there's something defined.  It is technically a change of spec, so it might not be possible.    A moderate suggestion is to be explicit as what the reference implementation does, i.e. "If id doesn't specify an existing task, or the task has already been run and not repeated, this procedure does nothing."