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.
That is certainly true. It's more a matter of implementation interoperability:
guaranteeing that separately written implementations of SRFI 170 and the future
date SRFI have the same representation so they can work together. That would be
made possible, if a little more awkwardly, by conversions from timespec record to
pair (or whatever) and back.
Is it too underspecified? To me, using a pair of integers looks arbitrary and we don't
gain much by specifying the concrete representation.
I chose pairs because MIT Scheme uses them, and because many Lisps have either
fast-path constructors or special compact representations (using tagged pointers)
for them. I realize that these considerations don't help Kawa any. The second/nanosecond
choice comes from Posix itself, of course, plus the fact that they
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.
Good point.
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.
Scheme's version of structural polymorphism is duck typing, and we could certainly do
that, but each implementation would have to expose its version of the primitive timestamp ops
in some way, probably as a list, a vector, or multiple values. This just pushes the problem
off to the meta level, as all would have to agree on *that* representation.
I suppose I could write a trivial timespec SRFI with a trivial implementation, and specify that
SRFI 170 must operate in terms of that and so must the date-time SRFI. If you feel strongly
about this, I will, but it feels like extra ceremony to me.