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 3:57 PM, Göran Weinholt wrote:
So what problem is solved by keeping the version inside the filename?
Derick's idea is that you may have two programs P1 and P2 where P1 depends on A.v1 and P2 depends on A.v2 and to be able to run both programs, you need to have both A.v1 and A.v2 at the same time. If the SRFI does not map files+versions to file names, then you can only have one of A.sls and not both of A.1.sls and A.2.sls. Now shift the problem a little, and let's say that P1 depends on A1 depends on B1, and P2 depends on A2 depends on B2. Yes, by having distinct file names, you can run P1 and P2, but you still cannot use the libraries A1 and A2 or B1 and B2 at the same time. If you put the version in the library name, as you suggest, and call these libraries A1, A2, B1, and B2, then yes, you can have them at the same directory and you can load them all at the same time. This may or may not be a good idea depending on what the library does.
There is something of a feature-creep in this SRFI as it currently stands. As I see it, the idea is to standardize the widely implementedlibrary file locator algorithm and work out all the edge cases. Keepingthe version number in the filename is not widely implemented, andcreates new problems by itself. Remove that feature and I think we willhave a less controversial SRFI that is also compatible with existing Schemes and libraries.
I agree with this. If the versions in this SRFI is providing a real solution to the problem, I would have no problem implementing it and ditching everything that already exists in Ikarus.
I'm all in favor of library versions and version references. I use them myself, as a courtesy to those who want to use my libraries, and becauseI want to be able to change the meaning of exported bindings without causing people too much trouble.
In Ikarus, versions are supported for the purpose of checking for availability of a certain version, and failing fast if the specified version does not meet the actual library version. I certainly am not going to add a SAT solver for picking which library must be used among a set of available libraries, and I certainly don't like to just pick the first specified one (which is random more or less) which is what this SRFI currently says I should do. I would like to keep version dependencies, constraints, conflicts, etc., outside of the implementation as much as possible. Aziz,,,