*Addendum* In order to implement all of SRFI 19, the following procedures will need to be added as well: (process-duration) Returns the duration spent in the process as a duration value. (thread-duration) Returns the duration spent in the thread as a duration value. *Clarification* As we know from special and general relativity, there is no such thing as absolute Newtonian time (this already influences the GPS system). So when I speak about absolute Newtonian time, I mean the proper time of Earth's local frame of reference whose direction is defined by local entropy increase. Thus, the flow of seconds of absolute Newtonian time in the sense of my proposal is the flow of seconds of TAI. *Clash of names* When both something like this proposal and a SRFI 19-derived interface are implemented in a future standard, the SRFI 19 counterparts could be renamed from time to clock, which also makes more sense, I think. *Possible problem with my proposal* While physically IMO the most sensible, formally, the threading functions of the C standard library and POSIX that take times as parameters (e.g. thrd_sleep) work on UTC time, so using these functions to implement SRFI 18/SRFI 226 wouldn't necessarily be straight-forward when SRFI 18/SRFI 226 is based on physical (TAI) time. On the other hand, I don't know whether a procedure like `thrd_sleep` really takes leap seconds into account. And if it does, it probably doesn't do what a user naively expects. Personally, I think `(thread-sleep 2)` should always sleep for two (physical) seconds (modulo non-real-timeness), and should not sleep for three seconds on some occasions. Am Mo., 10. Okt. 2022 um 18:48 Uhr schrieb Marc Nieper-Wißkirchen <xxxxxx@gmail.com>: > > PS Here is a minimal time API modeling (oriented Newtonian) time (and > not representations of time): > > (time? OBJ) > Returns #t if OBJ is a time value, and #f otherwise. > > (duration? OBJ) > Returns #t if OBJ is a duration value, and #f otherwise. > > (time- TIME1 TIME2) > Returns a duration value reflecting the time difference between TIME1 and TIME2. > > (time+ TIME DURATION) > Returns a time value describing TIME translated by DURATION to the future. > > (duration+ DURATION1 DURATION2) > (duration- DURATION1 DURATION2) > (duration* REAL DURATION) > Returns the result of the obvious calculation as a boolean value. > > (time=? TIME1 TIME2) > (time<=? TIME1 TIME2) > ... > Returns the result of the obvious comparison as a boolean value. The > same caveat as for comparing inexact real numbers applies. > > (duration=? DURATION1 DURATION2) > ... > Likewise. > > (current-time) > Returns the current time as a time value. > > (duration->seconds DURATION) > Returns an (inexact) real number representing DURATION in seconds. > > (seconds->duration REAL) > The other way round. > > (duration->nanoseconds DURATION) > Returns an (inexact) integer representing DURATION in nanoseconds. > > (nanoseconds->duration INTEGER) > The other way round. > > (epoch-time) > Returns the POSIX epoch as a time value. > > (process-time) > Returns the time value representing the time the process was started. > > (thread-time) > Returns the time value representing the time the thread was started. > > I think this is all that is needed for the system-dependent lowest > layer (suitable for the Foundations and SRFI 226). On top of that, > SRFI 19 or a modification of it can be built portably. > > > Am Mo., 10. Okt. 2022 um 08:26 Uhr schrieb Marc Nieper-Wißkirchen > <xxxxxx@gmail.com>: > > > > Am So., 9. Okt. 2022 um 22:29 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > > > > > > > > > > > On Sun, Oct 9, 2022 at 12:07 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: > > > > > >> > > >> By not exporting the record type itself but only its type predicate > > >> you would model an abstract record type in R6RS. > > > > > > > > > By an abstract type I mean one for which it is possible to create subtypes but not instances, as in C++. Java, or Python. > > > > I know; that's why I wrote only to export the type predicate (but not > > a constructor). > > > > That said, the notion of an abstract type doesn't make much sense in > > the SRFI 76/R6RS/SRFI 99/SRFI 131/SRFI 136/SRFI 150 model of records > > and inheritance. Assume that you had a record type "foo", which is > > abstract (in the above sense) and which you can inherit from. > > > > Then you just have to write > > > > (define-record-type foo2 > > (parent foo)) > > > > and you end up with an equivalent record type that is no longer > > abstract but whose instances are more or less equivalent to instances > > of "foo". > > > > In the context of C++ or Java, abstract base classes make sense > > because they have virtual methods that have to be overridden to create > > a non-abstract child type (so the above "foo2" example would not > > work). With Scheme records, the closest analog would be like this: > > > > (define-record-type abstract-base > > (fields method) > > (protocol > > (lambda (p) > > (lambda (method) > > (p (assert method)))))) > > > > (define abstract-base-do > > (lambda (this . args) > > (apply (abstract-base-method this) this args))) > > > > (define-record-type concrete-class > > (fields x) > > (protocol > > (lambda (n) > > (lambda (x) > > ((n method-implementation) x))))) > > > > (define method-implementation > > (lambda (this y) > > (+ (concrete-class-x this) y))) > > > > >> As far as an epoch is concerned, on the lowest level, I would not talk > > >> about this notion but would model the physical notion of Newtonian > > >> time. Maybe this is my main problem with SRFI 19 in the context of > > >> SRFI 226. SRFI 19 does not model Newtonian time; instead, it models > > >> representations (in terms of units) of the physical time observable. > > > > > > > > > It's true that SRFI 19 and friends don't deal in Newtonian time. Rather, they are a finite approximation to Leibnizian time, in which there is no "absolute, true and mathematical time", but only relative (not relativistic) time: time is what we infer from events, rather than events being situated in time. Note however that Newton himself said that his absolute time "by another name is called duration". So SRFI 19's time is perfectly respectable philosophically. > > > > I meant "Newtonian time" in the physical sense of the word (as opposed > > to time being a part of Minkowskian or general spacetime), so the > > philosophies of Newton or Leibniz do not necessarily apply. In any > > case, I understand Leibniz's point of view differently. I would > > Leibniz's point of view instead call Mach's principle (at least one > > form of it) applied to time alone (and not spacetime). What Leibniz > > says is that there is no independent time observable; instead, time is > > an observable dependent on other observables. For example, if I have > > an unchanging body in an otherwise empty universe, Leibniz would say > > that there is no time because there is no observable from which it > > could be derived. Now if the ball rolls on a line, a time observable > > can be constructed by equating time with the ball's position on the > > line. > > > > >> It would be the same as asking about the unit of measurement of some > > >> length like the distance between the earth and the sun. > > > > > > > > > I don't understand this analogy. > > > > With SRFI 19, you can ask for the type of a time value (e.g. UTC > > time), i.e. for the epoch. (But then we don't talk about (absolute) > > time itself, but obviously about a derived concept, namely a > > particular representation.) > > > > [...] > > > > >> It's again a question of representation and not of the underlying > > >> abstract entity. And even in the context of a representation, it is > > >> usually easier to work with single numbers (e.g. multiples of the > > >> jiffy) than with pairs of numbers. > > > > > > > > > Jiffies are often too long. I use nanoseconds because that is the unit of Posix file times, even though times are not kept as precisely as that on any actual file system. > > > > Nanoseconds would be fine with me as well. But what's the purpose of > > jiffies in R7RS then? > > > > [...]
