Email list hosting service & mailing list manager

dialect specificity [was: SRFI-59, SLIB, and SCHEME_LIBRARY_PATH] Derick Eddington 11 Oct 2009 02:41 UTC

On Sat, 2009-10-10 at 12:41 +0300, Vitaly Magerya wrote:
> Derick Eddington wrote:
> > On Thu, 2009-10-08 at 12:42 +0300, Vitaly Magerya wrote:
> >> Abdulaziz Ghuloum wrote:
> >>> The whole idea of using "SCHEME_LIBRARY_PATH" is to say where your
> >>> Scheme files are.
> >>
> >> SCHEME_LIBRARY_PATH in this SRFI only specifies where R6RS libraries
> >> are. If R^NRS libraries (for some N>  6) will not be compatible, you'll
> >> end up with the same kind of conflict.
> >
> > This SRFI intends to be usable by any dialect with library names being a
> > sequence of symbols.  That is why, in the Abstract, I wrote: "intended
> > for implementations of the R6RS, and perhaps other Scheme dialects".  Do
> > you think that should be made clearer?  I'm thinking I should add
> > something like the first sentence of this paragraph to somewhere in this
> > SRFI's document.
> The mapping of libraries to a file hierarchy described by this SRFI is
> quite generic, and will work with all dialects where normalized library
> names are symbol lists (sans versioning).
> What will not work is putting files from conflicting dialects in the
> same place (SCHEME_LIBRARY_SEARCH_PATHS in current draft).
> So if this SRFI is to be language-agnostic, it should specify how
> libraries from different dialects (e.g. R^NRS, SLIB) are to co-exist in
> a single location. If not then a single dialect should be chosen
> and SCHEME_LIBRARY_SEARCH_PATHS renamed to reflect that choice.
> Alternatively this whole part can be dropped.

I think you're right.  I had been thinking other dialects could use this
SRFI by adding to the search paths separate directories for files for
different dialects.  But that isn't good because the same library name
might be used for libraries for different dialects, and the file in the
earliest search path would shadow the files for other dialects.  To
avoid that problem, a different file name extension could be used for
different dialects.  But this SRFI specifies only one extension.  Also,
this SRFI specifies a dialect-specific format for the contents of files.
This SRFI would have to be substantially altered in order to support
multiple dialects.  I don't think that should be done.  So now I think
this SRFI should talk only about R6RS.

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.

Not using ".sls" would depart from the intent of this SRFI to
standardize what has already become a set of conventions for R6RS
library files.  So, I think that suggests this SRFI should choose the
option of using an "R6RS_"-named environment variable for isolating the
searching to only R6RS-specific files.

: Derick