| From: Derick Eddington <xxxxxx@gmail.com>
 | Date: Tue, 13 Oct 2009 10:45:43 -0700
 |
 | On Sun, 2009-10-11 at 22:45 -0400, Aubrey Jaffer wrote:
 | >  | From: Derick Eddington <xxxxxx@gmail.com>
 | >  | Date: Wed, 07 Oct 2009 13:23:45 -0700
 | >  | ...
 | >  | 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.
 |
 | Okay, so pre-computing paths of library files should not be done
 | from only the directory structure information.  An SRFI layered on
 | this SRFI should have some way of supplying the information of what
 | paths to pre-compute.

Thinking about it, why is this problem any different when precomputing
paths than when dynamically computing them?