SRFI 19 already effectively has a 'timespec' object Lassi Kortela (10 Dec 2019 22:44 UTC)
Re: SRFI 19 already effectively has a 'timespec' object John Cowan (10 Dec 2019 23:46 UTC)
Re: SRFI 19 already effectively has a 'timespec' object Lassi Kortela (11 Dec 2019 11:16 UTC)
(missing)

Re: SRFI 19 already effectively has a 'timespec' object Lassi Kortela 11 Dec 2019 11:15 UTC

> True.  However, SRFI 19 timespec objects are mutable, which I consider a
> Bad Thing.

You're right.

What bothers me is that we have different names for the same operations.
Since the 174 timespec API is a subset of the 19 time API, I'm hoping
SRFI 174 could be specified as a subset of SRFI 19 somehow, as there
have been SRFIs that are "reduced" versions of earlier ones.

Since the 19 API is:

* make-time type nanosecond second -> time
* time? object -> boolean
* time-nanosecond time -> integer
* time-second time -> integer

Perhaps the 174 API could be:

* make-immutable-time type nanosecond second -> immutable-time
* immutable-time? object -> boolean

And 174 would repeat these procedures from 19:

* time? object -> boolean
* time-nanosecond time -> integer
* time-second time -> integer

But would only specify them for immutable time objects. Schemes that
implement both 19 and 174 would have versions of these procedures that
support both objects. We'd need to think of the right language to
specify this in 174. Tricky but should be doable.

SRFI 19 doesn't have a time-hash procedure, which I guess is good since
time objects are mutable. We could have an immutable-time-hash for 174.

SRFI 19 has more useful procedures:

time<=? time1 time2 -> boolean
time<? time1 time2 -> boolean
time=? time1 time2 -> boolean
time>=? time1 time2 -> boolean
time>? time1 time2 -> boolean

time-difference time1 time2 -> time-duration
time-difference! time1 time2 -> time-duration
add-duration time1 time-duration -> time
add-duration! time1 time-duration -> time
subtract-duration time1 time-duration -> time
subtract-duration! time1 time-duration -> time

It would be a bummer to gratuitously repeat or be incompatible with all
this good stuff.

> In addition, the source code for them is not isolated from
> the rest of SRFI 19.   I've added some new language (in the
> johnwcowan/srfi-174 repo) to explain the limitations on using SRFI 19 to
> help implement SRFI 174.

Thanks!

I think the source code can be arranged if we can agree on the interface.