On Fri, Oct 7, 2022 at 5:36 PM Marc Nieper-Wißkirchen <[email protected]> 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. > 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 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. > 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.
