On Fri, 2009-11-27 at 21:34 -0500, Aubrey Jaffer wrote:
>  | 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?

With dynamic computing, as with precomputing from directory structure,
if there are junk files whose names look like they're for some
libraries, those files will unintentionally shadow other matching files
with lesser precedence.  So there isn't a difference in that regard.

Dynamic computing allows reconfiguring the search paths or library files
to take effect without further action, but precomputing requires
additional action of registering the changes.  That is an advantage of
dynamic computing.

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