Am Fr., 7. Okt. 2022 um 18:22 Uhr schrieb John Cowan <xxxxxx@ccil.org>:

>> I don't understand the logic behind the design choices of SRFI 19
>> fully. For the purpose of SRFI 226, it is specifying much more than
>> what is needed (and the split between seconds and nanoseconds is
>> arbitrary in view of this SRFI). But we probably want more than just a
>> duration but also an absolute time to specify a concrete time in the
>> future.
>
>
> Indeed, SRFI 19 specifies more than is needed for any given use case, but I think that  it is much better than having many individually tailored types of absolute time and duration objects.  SRFI 19 was there first (so it is already widespread) and is sufficiently general (note that by "SRFI 19" I mean the data structure, not all the conversions) to cover all the cases.  I want to use it everywhere in R7RS-large.

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.

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.

>>  in SRFI 19,
>> a time duration is also a time. I don't want to follow this because it
>> is like comparing apples with pears.
>
>
> That troubled me too at first, until I realized that a duration can be viewed an absolute time whose epoch is context-dependent, rather than itself being absolute as with the other SRFI 19 epoch settings.

By the same reasoning, the difference in the concept of a point and a
vector in the context of affine spaces would collapse. This, for sure,
does not help to understand these concepts and looks misguided to me.

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), which, however, could be implemented in terms of
an existing SRFI 19. I think it also makes sense to make time objects
immutable (which they aren't in the SRFI 19 proposal). Specifying
procedures that have to deal with mutable arguments is hard. And
mutability is not really needed.

In any case, these are just first thoughts, so to speak.