Am Sa., 8. Okt. 2022 um 02:13 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > > > On Fri, Oct 7, 2022 at 5:36 PM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote: > >> >> I agree that we should not double types in the large language. But I >> think we should nevertheless be careful to have suitable abstractions. >> I think this is more important than having an exact copy of SRFI 19. >> Should R7RS-large get inheritance (see SRFI 237), one can also ask >> whether the SRFI 19-like "type symbols" fit the rest of the language. > > > In order to do that, we would have to have abstract (non-instantiable) record types, because the supertype would be epochless and instantiating it would be a mistake. I don't know if that's possible with R6RS records. But I don't think there's any overwhelming benefit from it, even if it is possible. By not exporting the record type itself but only its type predicate you would model an abstract record type in R6RS. 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. Given an absolute time, it does not make sense to ask for its epoch. It would be the same as asking about the unit of measurement of some length like the distance between the earth and the sun. Or asking about the origin of Euclidean space modelling the Newtonian universe. So, given an abstract time object, there should not even be a procedure like `time->seconds` or similar. This only makes sense for time durations. So coming back to your remark on viewing durations as times or vice versa, I now understand better that whenever SRFI 19 speaks of a time, it really means a duration and fails to abstract the concept of absolute time. >> Finally, to be able to build Scheme in layers, a very low-level SRFI >> like 226 should not rely on high-level SRFIs like SRFI 19. Maybe a >> trimmed-down SRFI 19-core, which can be part of the Foundations is a >> good idea. And a full SRFI 19, building on the core, would appear in >> the Batteries. > > > I agree. <https://github.com/pre-srfi/time-objects/blob/master/TimeObjects.md> is a SRFI-19-compatible upgrade of SRFI 174, and I think that works for this purpose. I will take a look at it, but my issue described above will probably apply to it as well. >> >> I would therefore propose writing a "modern" version of SRFI 19 (in >> particular one, where the nanosecond-second split is not at the heart >> of the description), > > Why not? Daphne's model is days and fractions of days; we could use a nanosecond bignum, or a rational value, or anything. On a 64-bit system, seconds and nanoseconds are fixnums, hence efficient. 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. I'm not saying that the split has no use cases and that it is used to implement time objects but it should not be at the heart of the API. >> I think it also makes sense to make time objects >> immutable (which they aren't in the SRFI 19 proposal). > > > SRFI 174 timespecs may be mutable if they are SRFI 19 objects, but there are no mutators in SRFI 174. TimeObjects are in fact immutable. 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.
