We don't need to specify implementation of timespec at all in srfi-170.   As long as it
responds to the given API, it can be a pair or a record or a vector or even a bignum.
Is it too underspecified?   To me, using a pair of integers looks arbitrary and we don't
gain much by specifying the concrete representation.

Having comparator is a good idea.  One drawback of using non-disjoint type for
timespec is that such comparator can't be passed to comparator-regeister-default!.
But it can be a trade-off with giving choice to the implementations.

<sidenote>
Aside from srfi-170 and generally speaking, record interoperability is certainly
an issue of current srfis where we don't want to bind implementations with lots
of dependencies.  Using structural polymorphism might be easier but that
isn't Scheme's way, I guess.
</sidenote>






On Wed, Jul 3, 2019 at 5:51 PM John Cowan <xxxxxx@ccil.org> wrote:


On Wed, Jul 3, 2019 at 8:51 PM Shiro Kawai <xxxxxx@gmail.com> wrote:

In 3.10, the expression to convert timespec into inexact seconds appears to
be missing close parentheses for car and cdr.

Thanks, fixed.
 
But I feel that it's better to have timespec as an implementation-dependent
data structure, rather than a pair of integers. 

Originally it was.  But then I realized I would need it in my date-time SRFI, which I am
also working on, and it was important for them to interoperate.  Using a
record type would make it awkward for different implementations of 170
and date-time to interoperate, since define-record-type always creates a new
record-type whenever it appears.  I suppose I could go with a record that
can be converted to and from a pair, but it seems unnecessary.
 
We already have timespec-difference and timespec=?, which are technically unnecessary
we do specify timespec is just a pair.

I realize that what we want is not = but a comparator.  Time difference is valuable, though.
 
   To add (make-timespec seconds nanoseconds),
(timespec? timespec),  (timespec-second timespec) and (timespec-nanosecond timespec),
we can leave the concrete data structure of timespec to implementation's choice.

That is certainly not hard if the interoperability concern is overcome. 


John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
How comes city and country to be filled with drones and rogues, our highways
with hackers, and all places with sloth and wickedness?
                --W. Blith, Eng. Improver Improved, 1652