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.)

> It has been my long experience that dynamic search-paths are
> disastrous for libraries on large industrial and educational computer
> networks.  The search-paths at these sites seem to only grow; it is
> not uncommon for half of the directories in a path to refer to
> non-existant directories or non-functioning host machines!  The
> timeouts from hosed or inaccessible networked-file-systems can inflame
> into minutes the startup time for programs.
>
> Furthermore, transient router outages can cause incompatible versions
> of libraries to be loaded which, in the Scheme or Lisp case, may not
> be noticed until the program has run for hours; but more likely will
> just cause a mysterious failure.
>
> SLIB's solution to this problem is to have an explicit command
> [(require 'new-catalog)], typically run after installations, write to
> a file an association list of features and resolved pathnames.  SLIB
> sessions read this file and thereafter have instantaneous latency to
> library paths.
>
> If the network can't reach a particlar file, the session fails
> immediately or after the first timeout rather than conducting covert
> experiments on library version compatibility.

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.

> SRFI-59 and SLIB use the environment variable SCHEME_LIBRARY_PATH to
> configure their single Scheme-source library directory.  If SRFI-103
> appropriates SCHEME_LIBRARY_PATH for its use, it will cause SRFI-59
> and SLIB supporting implementations (of which there are many) to fail.
>
> 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.

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