I sent Shiro an (accidentally private) response last week that I now think was unsatisfactory. Here's a completely different public replacement.
What I'm thinking is to let srfi-174 not care the time type, as far as it is used as a timespec object.
The constructor `timespec` could return time-utc if the implementation chooses to use srfi-19 time.
But other srfi-174 procedures would accept other time types just as well.
I can't swallow a SRFI 19 object being set to time-utc when in fact it is going to be a monotonic time, and of course the SRFI 174 constructor doesn't know what the purpose is going to be: all it gets are seconds and nanoseconds.
[solution 2 snipped as unsatisfactory]
3) Drop time-monotonic from SRFI 170. No problem.
I really dislike this one too: it solves the problem by moving it further away.
4) Replace the use of SRFI 174 in SRFI 170 with the SRFI 19 time types. I'd probably write a SRFI that exposes just the time operations of SRFI 19, so that you don't need a full SRFI 19 implementation.
I think this is the only full solution, and it entails abandoning the use of SRFI 174 altogether. The replacement SRFI will be required to be compatible with SRFI 19 (i.e. if an implementation has both, the types are the same).
With this in mind, I have changed `posix-time` to return a SRFI 19 compatible time object with the type set to time-utc and `monotonic-time` to return one with the time-type set to time-monotonic. By the same token, the `file-info:?time` procedures return and `set-file-timespecs!` accepts SRFI 19 compatible time objects as well.
The only visible effects on the implementation are that set-file-timespecs!, timespec/now, and timespec/unchanged have become set-file-times! (the original scsh name), time/now, and time/unchanged. Internally no other changes are required, since Chibi does not implement SRFI 19 anyway.
For example, nanosleep() takes struct timespec, but it's use is `time-duration` in
the sense of srfi-19, and we'll stumble again if we want to use srfi-174 timespec for the purpose.
Just so, which is why it is better to use SRFI 19 (or future SRFI 174 replacement) time objects from the start. Current implementers of SRFI 19 are Chez, Chicken, Gambit, Gauche, Guile, Larceny, Mosh, Racket, Sagittarius, Scheme48, scsh, Vicare, Ypsilon.
A very early pre-SRFI is available at <
https://github.com/johnwcowan/r7rs-work/blob/master/174bis.md>. The only difference other than the names is that `make-time` takes three arguments: time, nanoseconds, seconds in that order. It exports the relevant SRFI 19 constants (6) and procedures (13), plus SRFI 19 style equivalents of the SRFI 174 procedures `time->inexact`. `inexact->time`, and `time-hash`.
John Cowan
http://vrici.lojban.org/~cowan xxxxxx@ccil.orgIf a traveler were informed that such a man [as Lord John Russell] was
leader of the House of Commons, he may well begin to comprehend how the
Egyptians worshiped an insect. --Benjamin Disraeli