[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Keeping the version in filenames

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 7:22 PM, Derick Eddington wrote:

If a library
developer wants to do that, he can simply append a major version to the
end of a library identifier, something like this:

(foo jpeg (0))   foo/jpeg.sls   initial version (0 is the minor)
(foo jpeg (1))   foo/jpeg.sls   second version, supports more formats
(foo jpeg1 (0))  foo/jpeg1.sls  third version with a much better API

If he wants to he can even make it so (foo jpeg) is a compatibility
wrapper around (foo jpeg1). Such a wrapper would be very useful for
anyone changing a program to use the new library, because it would show
exactly what changes are necessary. And if the developer was careful,
there will not be any point in keeping (foo jpeg (0)) around when you've
got (foo jpeg (1)).

This is much less tedious than requiring that every part of a version
reference always must be included in the filename, and it leaves the
individual developer free to choose what he and his users need.

Problems with this scheme are: semantic disintegration between major
numbers and minor numbers, version constraints cannot be used on major
numbers, and an additional redundant versioning convention to deal with.

It's not redundant; it's just different.  Versions as part of the
library name allows for two different libraries to exist at the
same time (at the Scheme level and at the file system level).
Whether that's desirable or not depends on the specific library.

Libraries with different R6RS versions (separate from file names)
cannot coexist at both the Scheme level or the file system level.
Again, whether that's desirable or not depends on the specific
library.

Libraries with different R6RS versions (named according to this
SRFI) can coexist at the file system level but cannot coexist
at the Scheme level.  Furthermore, which combinations of them
actually work together, and which combination will be picked by
the implementation are both unspecified.

So, I'm now totally confused about what the real problem that
you're trying to solve.

I think putting any part of the version in the last symbol (or any
symbol) is going against the purpose of compound library names.

I disagree.  I did object to the final draft of R6RS when it
renamed the libraries from (r6rs *) to (rnrs * (6)) and I did
list the reasons for why, but no one listened.  I'm too lazy
to look it up now.

Aziz,,,