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. 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. > 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. > I will take a look at it, but my issue described above will probably > apply to it as well. > Yes, my time objects are also Leibnizian. 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. > The more I think about it, the more reasons I find that immutability > should be specified. Think of a scheduler library that exports a > "default-quantum", which is a time (difference) object. Mutating this > would play havoc. > I agree that immutability is the Right Thing.
