On Sat, Dec 12, 2009 at 4:16 AM, Vitaly Magerya <xxxxxx@gmail.com> wrote:
> Derick Eddington wrote:
>> With the previous revision which didn't support different file name
>> extensions for different dialects, different dialects could not share
>> the search paths environment variable because different dialects would
>> be using the same extension and so a file for one dialect could
>> unavoidably shadow a file for another dialect.  With different
>> extensions, that problem doesn't exist and different dialects can
>> share the environment variable.
>
> OK, now I think I got it. Different extensions for implementations are
> introduced not to be able to put different implementation-specific
> libraries into the exact same folder (which was my objection), but to
> resolve shadowing which may occur when SCHEME_LIB_PATH lists several paths.

Different extensions exist both to avoid shadowing and to put
different libraries in the same folder.

(In the previous revisions, I used to say "implementation" and
"implementation-specific" to mean a particular Scheme system from the
set of systems implementing the same dialect.  Now, I say "system"
instead of "implementation", to mean the same thing.)

This SRFI supports: files for multiple Scheme dialects, files for
multiple systems of the same dialect, and files specific to a
particular system and dialect.

Let's say we have two dialects: R6RS and Thing2.  Let's say there are
two systems implementing R6RS: Foo and Bar.  Let's say there are two
systems implementing Thing2: Foo and Zab.  Notice that system Foo
implements both dialects.  We want files usable by any system of a
particular dialect, and we want files specific to a particular
system+dialect.

An example of what I've been thinking is:

SCHEME_LIB_PATH=/home/me/R6RS:/home/me/Thing2:/scheme/R6RS:/scheme/Thing2
SCHEME_LIB_EXT undefined

/home/me/R6RS/
    asdf/
        README
        main.r6rs-lib
        compat.foo-r6rs-lib
        compat.bar-r6rs-lib

/scheme/R6RS/
    acme/
        README
        main.r6rs-lib
        compat.foo-r6rs-lib
        compat.bar-r6rs-lib

/home/me/Thing2/
    asdf/
        README
        main.thing2-module
        compat.foo-thing2-module
        compat.zab-thing2-module

/scheme/Thing2/
    acme/
        README
        main.thing2-module
        compat.foo-thing2-module
        compat.zab-thing2-module

The (asdf ---) and (acme ---) libraries for the different dialects all
use this SRFI, and they might provide the same functionality in both
dialects, or they might be totally different and just have the same
names.  (If a system like Foo which implements both dialects desires
to allow both dialects to be simultaneously used, resolving issues
about multiple same-name different-dialect libraries is outside this
SRFI.)

Having separate folders for different dialects is done to keep the
dialects separate so they can have independently-distributed libraries
(folders and files) with the same names, and because it seems better
organized.  Having same-dialect system-specific files for different
implementations of a library in the same folder is done because they
are usually distributed (e.g. simply un-tar-ed in a search path) and
worked-on together, and so grouping them together is better.

This SRFI also supports configurations like:

SCHEME_LIB_PATH=/scheme
SCHEME_LIB_EXT undefined
FOO_LIB_PATH=/scheme/foo
BAR_LIB_PATH=/scheme/bar
ZAB_LIB_PATH=/scheme/zab

/scheme/
    asdf/
        README
        main.r6rs-lib
        main.thing2-module
    acme/
        README
        main.r6rs-lib
        main.thing2-module
    foo/
        asdf/
            README
            compat.r6rs-lib
            compat.thing2-module
        acme/
            README
            compat.r6rs-lib
            compat.thing2-module
    bar/
        asdf/
            README
            compat.r6rs-lib
        acme/
            README
            compat.r6rs-lib
    zab/
        asdf/
            README
            compat.thing2-module
        acme/
            README
            compat.thing2-module

But this is not as well-organized (IMO) and involves more burdensome
management of environment variables and files/folders.

Other configurations are also possible.

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