On Sat, 2009-10-10 at 19:41 -0700, Derick Eddington wrote:
> I'm starting to think that either the environment variable name should
> start with "R6RS_" or the file name extension should be something like
> ".r6rs-lib".  If SCHEME_LIBRARY_SEARCH_PATHS (or whatever name) is for
> Scheme library files in general (which means files of any dialect), then
> the files need dialect-specific extensions so they can be distinguished
> and so not cause conflicts.  If this SRFI uses the ".sls" extension
> (which means "Scheme library source"), then R6RS-specific files using
> that extension need to be searched separately from other dialects'
> ".sls" files which are also "Scheme library sources" so that conflicts
> cannot happen.

I thought of something else I'd like to mention.

This SRFI could change so that it has a configurable "searched file name
extensions" parameter, and it could lose the current design for
implementation-specific file name extension, and implementation-specific
files could be accomplished by using and searching for extensions like
".acme-r6rs-lib" (for an implementation named Acme).  I think this might
allow this SRFI to be usable by any dialect with symbol-list library
names because different dialects can use different extensions.  And, at
the same time, this supports implementation-specific files which are
equivalent (I think) to the current design.  This would also free the
#\. character from needing to be encoded.

Does anyone think this is worth exploring further with this SRFI?

If this SRFI changed like that, how would that influence what file
formats it should specify?  Should it specify none and leave it to other
SRFIs?  (I could submit a new SRFI for R6RS extensions.)  Or, should it
specify one/some (e.g. the R6RS format of the current draft, for the
extension ".r6rs-lib")?

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