| From: Derick Eddington <xxxxxx@gmail.com>
 | Date: Wed, 07 Oct 2009 13:23:45 -0700
 |
 | On Wed, 2009-10-07 at 13:34 -0400, Aubrey Jaffer wrote:
 | > SRFI-103 should have some text comparing SRFI-59 to SRFI-103 and
 | > explaining why the conventions of SRFI-59 are inadequate to your goals
 | > for SRFI-103.
 |
 | Thanks for pointing-out SRFI-59.  I just read it for the first
 | time.  I need more time and sleep to think about it, but right now
 | I'm thinking it probably is not a fit for this SRFI, and I probably
 | can succinctly describe why in the document of this SRFI.  I'll
 | return to this topic.  (Anyone, feel free to comment about this if
 | you want while I wait.)

I got a chance to look at SRFI-104, and SRFI-59 has relevance there.
I posted comments to srfi-104@srfi.schemers.org.

SLIB's library system allows compiled files (with the same base-name)
to be loaded in preference to source files.  The words "compiled" and
"binary" don't appear in SRFI-103.  Shouldn't compiled files be
supported?

 | ...
 | Thanks for pointing-out these issues.  The latency of always (i.e. for
 | every program start-up) dynamically finding library files (which is what
 | I think you're talking about) does sound like a serious concern for
 | situations like you describe (i.e. unexpectedly long network file system
 | latency).  However, I think addressing this is beyond the purpose of
 | this SRFI.  This SRFI's purpose is to standardize what has (at this
 | early stage) become the conventions for finding files of R6RS libraries.
 | I think addressing the kind of issues you describe can be done with
 | another SRFI which seamlessly fits on top of this SRFI (right?).  I
 | welcome more feedback about this.

If one tries to pre-compute paths when the only information is the
directory structure, then one must register all the files.  In order
to not register unintended files, the directory structure must be
pristine, which is not always how humans work.  Looking at my
development directories, I find experimental, test, patched, and
backup files nestled among the source-controlled files.

 | ...
 | > Please don't adopt the environment variable SCHEME_LIBRARY_PATH.
 |
 | Okay, this SRFI will use a different environment variable name.
 | Should it be SCHEME_PATH?  Or something else?  SCHEME_PATH, being
 | shorter, seems even more prone to conflict with others choosing it.

I thought SCHEME_LIBRARY_PATHS was okay.