Separate "timespec" srfi does seem overkill.  

Would it be awkward that both srfi-170 and future date SRFI define the same set of
operations on an abstract timespec?  Possibly the date srfi refers to srfi-170 and recommends
implementations to use the same datatype.

One issue I can think of that when a Scheme implementation wants to use reference implementation
of the future date srfi as is, and its timespec implementation differ from the one in its the native posix
interface.  It would be confusing for users to have two different data struct with the same
name and operations.  However, I'd imagine it's not difficult for such Scheme implementations to modify
the reference implementation to use its native timespec data structure in date SRFI.

Another issue is that if Scheme implementation doesn't allow to import the same identifiers
from different libraries (as in R6RS); in that case, a user code that uses srfi-170 and date srfi needs
some extra renaming or excluding in import clause.   Is it the issue you want to avoid?

On Thu, Jul 4, 2019 at 5:01 AM John Cowan <> wrote:

On Thu, Jul 4, 2019 at 12:51 AM Shiro Kawai <> wrote:

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.

John Cowan
        You tollerday donsk?  N.  You tolkatiff scowegian?  Nn.
        You spigotty anglease?  Nnn.  You phonio saxo?  Nnnn.
                Clear all so!  `Tis a Jute.... (Finnegans Wake 16.5)