Am Fr., 28. Okt. 2022 um 20:59 Uhr schrieb Marc Feeley <[email protected]>: > > > > On Oct 28, 2022, at 2:25 PM, Marc Nieper-Wißkirchen > > <[email protected]> wrote: > > > > For all use cases, I can think of, SRFI 226 needs only two procedures > > that deal with times: > > > > (time? OBJ) > > Returns #t if OBJ is a time value representing a point in (proper) > > time, #f otherwise. > > > > (nanoseconds-from-now N) > > Returns a time value representing N nanoseconds from the time of > > invoking this procedure. > > > > For convenience, one can add a third procedure: > > > > (seconds-from-now X) > > Returns a time value representing X seconds from the time of invoking > > this procedure. > > > > This very minimal interface should be compatible with any high-level > > or extended API. > > > > Do you like the names "nanoseconds-from-now" and "seconds-from-now", > > or have you thought of better names? > > > > Thanks, > > > > Marc > > > > Calculating time relative to now using (XXX-from-now …) is only useful if you > need to compute a single time in the future. It leaves no option for > computing precisely two or more times in the future that have a fixed delta. > For example: > > (let* ((t1 (seconds-from-now 10)) > (t2 (seconds-from-now 15))) > …) > > The times t1 and t2 are only approximately 5 seconds apart because execution > takes time in an unpredictable way (e.g. process was interrupted or swapped > out between the two calls).
That's a very good point. > It is better to have a way to add some seconds to a given time to get another > time, for example (seconds+ <seconds> <time>) -> <time> . The above would > become: > > (let* ((now (current-time)) > (t1 (seconds+ 10 now)) > (t2 (seconds+ 15 now))) > …) > > And for the simple case you have (seconds-from-now 10) = (seconds+ 10 > (current-time)) , which is not even that much longer. I have to think about the name, but yes, this is what need. And it is shorter than SRFI 18's (seconds->time (+ 10 (time->seconds (current-time)))) (I know that SRFI 18 allows "raw" real numbers as time differences from the current time (when used as timeouts) and this is what is still in draft #2 of SRFI 226. But I would like to make the interface "type-safer" in anticipation of future time APIs.) > As for (nanoseconds-from-now N) I think it is sufficient to just use seconds. > In 20 years nanoseconds might be “old school” and you really want > picoseconds, in 50 years femtoseconds, etc. What is wrong with expressing > short times in seconds, the SI unit for time? I would be fine with just seconds; others have voiced the wish for nanoseconds, including John. But we can leave nanoseconds out for SRFI 226; future time APIs can add such procedures.
