This page is part of the web mail archives of SRFI 103 from before July 7th, 2015. The new archives for SRFI 103 contain all messages, not just those from before July 7th, 2015.
On Sat, Dec 12, 2009 at 4:16 AM, Vitaly Magerya <vmagerya@xxxxxxxxx> 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 ----------------------------------------------------------------