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.

--
: Derick
----------------------------------------------------------------