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 <[email protected]>: > > Am So., 9. Okt. 2022 um 22:29 Uhr schrieb John Cowan <[email protected]>: > > > > > > > > On Sun, Oct 9, 2022 at 12:07 PM Marc Nieper-Wißkirchen > > <[email protected]> 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? > > [...]
