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.
[I have put extra time into trying to make this email clear, insightful, and productive.] On Wed, 2009-09-30 at 09:11 -0400, William D Clinger wrote: > Derick Eddington wrote: > > Library references, in the current draft SRFI, > > always do have a one-to-infinite mapping to file names, because an R6RS > > version reference, including an empty/non-existent one, always matches > > versions with more components than in the version reference, and the > > possibilities are infinite. > > I appreciate the clarification. Thank you for helping analyze this draft SRFI. > As I predicted in a message sent to r6rs-discuss before > the ratification vote (but am too lazy to look up right > now), the version number is being treated as part of the > library name, but with special rules that add complexity > to both the semantics as seen by programmers and to > implementations. Do you think versioning should be treated, in any way, as part of the library name and/or library reference? Treating it as part of both makes a lot of sense to me. Version 1.2 of a library is a different thing than version 0.7. In natural language, when we refer to a versioned library, it's normal to call it "Foo 1.2" because that's the name of that distinct thing, and it's normal to say "Foo greater than 0.7" when referring to what library to use. I expect versioning in names and references to be treated with special rules because the purpose of having versioning in them is to have special semantics. Different versions of libraries, and so version constraints, are reality. The complexity added by versioning is not going away, it's just a matter of where it gets pushed to. I think it makes a lot of sense to have the language support versioning in the same way we use it in natural language: as part of the name or reference, as part of the language, at the syntactic site libraries are named or referred to. Until someone convinces me why that shouldn't make sense to me, I'm going to desire versioning support like R6RS's and desire to support it in this SRFI. A personal example: I have built a library (let's call it A, for below) on top of someone else's library, and their library (let's call it B) already comes with its own version numbering and I made it into an R6RS library with the version in the name. Older versions of it are not acceptable for my library but would correctly import. So, I used version constraints to make only versions great enough acceptable. If I were not sure future new series of versions would be acceptable, I could also further constrain the acceptable versions. If I did not have version constraints and only had versions as a non-special part of a library name, I could refer to only one version which is acceptable. That does not seem acceptable because of the following possible problem: library A, which can refer to only one version of library B, is stored such that it cannot be modified by some user; some library C needs to use a version of library B different than the version library A refers to but which library A could have also used; the user needs to use libraries A, B, and C in the same program; for this case, it is not acceptable to have two different versions of library B instantiated; therefore, the user cannot run the program, which could have been run if only libraries A and C could refer to library B such that a single version acceptable to both could be used. The user might be able to hack around this problem by making a copy of library A and modifying it and modifying the search paths to use it, but the user probably isn't sure it can use the same version of library B which library C needs, and even if the user is sure, I don't find the ability to hack around the problem a convincing justification for why multiple-version-allowing version constraints in library references are not needed. How do you think the above problem should be solved? > The mapping from library references to file names is > one-to-infinite, but this draft SRFI still contains > design decisions and rationales that are based upon > the utility of one-to-one mappings between library > names and file names. > > I maintain that the one-to-one mapping doesn't really > exist given the realities of this draft SRFI, A reality of this draft SRFI is that there is a one-to-one mapping from file names (possibly with versions) to library names (possibly with versions), and that this can be utilized. The utility of single-library files, whose name exactly represents the name of the contained library, exists whether or not this SRFI supports R6RS's library names and versioning. The draft has such single-library files so that: * People and programs can analyze a file name listing and from only that know what libraries and their versions are present and where, by taking advantage of the one-to-one mapping. * If we want to find the files which satisfy a library reference (whether or not we have library references which allow an infinite number of possible versions), we need to deal with only file names and we don't have to search through the contents of multiple-library files. * If we want to do something with a file containing the library with a given name (possibly with a version), we can one-to-many map the library name to a bounded set of file names, and know only that library is in a file with one of the file names. Thank you for helping me distill these design rationales. I will revise the draft to attempt to better convey them. I apologize for confusing the issue with less apt wording; I was trying to be very succinct. > from > which I conclude that the design decisions and rationales > based on that nonexistent mapping should be reconsidered. If it were not proper to consider versioning as part of the library name and library reference, I'd agree with that conclusion. But I don't see why versioning, including version constraints, is not properly considered part of them, and so not properly part of the file name in a scheme designed for utilizing single-library files with names which exactly represent the name of the contained library. My position has swayed towards being more in favor of the current draft's versioning support. -- : Derick ----------------------------------------------------------------