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 Oct 2, 2009, at 4:06 PM, Derick Eddington wrote:
I look at the issue like this:This SRFI needs to support having multiple versions of a library storedas separate files in the same directory.
I disagree. More to follow.
The only way to accomplish that is by having versions in file names.
There may be other ways like having multiple versions in one file. [I'm not advocating this either]
It is important to support having multiple versions available so that different programs which require different versions can both be used.
But different libraries requiring different versions still cannot be used together. At the extreme case, when every program just contains a call to "main" of some library, you'd still have to deal with this issue some other way. That other way, whatever it is, can still be applied to the situation when you have multiple programs. However, this SRFI does not describe that other way that solves the problem; instead, it advocates the nonsolution of having multiple sets of libraries all available at the same time and for which only certain combinations work, and only in an unspecified implementation-dependant manner. This is unacceptable.
If the file naming scheme does not support versions, the only way to accomplish running the different programs is to manage configuring the search paths used for each program so that the correct version is used.
Programs are not the problem. (If Scheme were an operating system, then all programs would have to run in the same OS instance; how would I run many programs that have conflicting sets of imports?)
We should be able to know what libraries are present, which includes knowing their versions because different versions are distinct things, ...
Ahem. The SRFI draft says what amounts to giving the implementation the freedom to choose what version depending on some unspecified order of exploring the transitive closure of imports and what happens during the traversal. So, if Ikarus traverses the imports left-to-right and Larceny traverses them right-to-left, we might get combinations of libraries that can be loaded in one system but not the other. This is not good. I would rather have this SRFI omit all mention of versioning altogether rather than specify something that's not good [we have plenty of that already]. If you have a better idea for how to handle versions, please put it in another SRFI. I *WANT* all implementors to adopt the same library file naming convention. This is making it hard.
I want to make sure everyone has thoroughly thought about these points before sacrificing the qualities of the current draft for the sake of not being annoyed by file renaming.
I understand your points, but I disagree. The way I look at it is that R6RS's versioning is not good because it has the wrong granularity. (and yes, I wish R6RS did not include versions too, and just because R6RS says libraries have version by no means says that this SRFI has to support them) Please leave conflicts, dependencies, etc., outside of this SRFI and keep it focused on mapping library names to file names only. Thanks. Aziz,,,