Sounds good to me. 

On Fri, Jul 5, 2019 at 12:03 AM Shiro Kawai <> wrote:
Would it be acceptable for srfis (in our case, future date srfi) to note that "if the implementation also supports srfi-170, these identifiers
exported from this srfi must be identical to srfi-170's".   Then the identifier conflict / record disjointness issue won't arise 

On Thu, Jul 4, 2019 at 5:19 PM John Cowan <> wrote:

On Thu, Jul 4, 2019 at 11:00 PM Shiro Kawai <> wrote:

Separate "timespec" srfi does seem overkill.  

I think our best bet is what you suggest below.
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.

Worse than that, they would not interoperate even if the names were the same.  In R7RS, if two record types are defined in different libraries, they are completely disjoint.  The only ways to avoid this is for one library to import from the other or for both to import from a third library.  (I think this is true in R6RS also, but I am not sure.)

  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.

True.  I think the Right Thing is to put a timespec definition in a separate file (not library), to be included only on those systems that do not implement SRFI 170, and all others must import from their local SRFI 170.  This is easy to do with cond-expand.

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?

That's also a problem.  I have always tried to make sure that no two libraries in R7RS-large export the same identifier unless one is a complete replacement for the other, such that there is never any point in importing both libraries; or one library is importing from the other and re-exporting, which is safe.

Doing otherwise means a careful check and (import (only ...)), unless the implementation is polite enough to complain about such import conflicts in detail rather than just saying "Import conflict between (foo) and (bar)" or worse yet letting the second import override the first.

John Cowan
XQuery Blueberry DOM
Entity parser dot-com
Abstract schemata / XPointer errata
Infoset Unicode BOM                                 --Richard Tobin