On Nov 10, 2006, at 5:08 PM, MichaelL_at_frogware.com wrote:
>> The situation changes with multiple developers or with libraries
>> pulled
>> from central code repositories (like PLT's planet, Perl's CPAN,
>> Chicken
>> Eggs, Ruby Gems, ...). In these situations, it is better to have a
>> single agreed-upon versioning scheme to specify exactly what the
>> import
>> requirements for a library are. You want to be able to look at a
>> library and figure out exactly what it needs rather than attempt to
>> guess what versioning scheme was used.
>
> Thanks; that's interesting. I'd like to think about it more. (Basically
> what I hear you saying is that whether or not it's useful *inside*
> Scheme
> it's potentially useful *outside* Scheme. I hadn't thought of that.)
Yes. Version numbers are pretty much useless for Scheme since your
Scheme code really only relies on the macros and variable bindings that
the library exports. The body of the importing library does not use
the version number at all (except inside the environment specifier for
eval but that's the same as the version in the import form more or
less).
>> Moreover, it gives you the
>> option of upgrading a library (using minor versions) without having to
>> go through every single file in your system (or in the world) to
>> rename
>> the imported library names.
>
> Imagine that there's a regexp library, and imagine that we were using
> v3.2
> and now v3.3 has come along. If the library was originally called
> regexp-3.2 I agree that we'd now have to visit all libraries to change
> regexp-3.2 to regexp-3.3. So far so good. I disagree, however, that
> separate version numbers would really help--at least, not in the way
> you
> think they would.
In my reply, I meant to say that having a version as part of the
library specifier is better than having the version number part of the
library identifier as in (regexp (3 2)) is better than regexp-3.2. My
motivation is that if you don't specify a versioning scheme in the
language, people are going to reinvent all sorts of versioning schemes
in existence for their scheme libraries including regexp-3.2,
regexp_3.2, regexp-20061109, regexp-3.1b-rc2, and so on and so forth.
I would rather have a simple way of specifying the required version
(like a list of exact nonnegative integers) with a single unambiguous
interpretation over having an ad hoc do-it-yourself version specifier.
> With the current syntax, you could import the regexp library with one
> of
> the following:
>
> 1. regexp
> 2. (regexp (3))
> 3. (regexp (3 2))
> 4. (regexp (3 2 5))
>
> It's true that if you used option 1 or 2 you wouldn't have to change
> any
> imports. At the same time, it's true that you've just shifted the risk
> elsewhere--the risk that the new v3.3 libraries are compatible with
> v3.2.
> It's possible that v3.3 changed its interface, in which case you'll
> get a
> compile-time error, and it's possible that v3.3 changed its contract,
> in
> which case you'll get a run-time error. If you don't want that kind of
> risk you'll have to use option 3--and you're back to where we started
> from. When v3.3 comes out you'll have to visit the libraries that used
> v3.2 to see if they're safe to switch to the latest version, and if so
> you'll have to note that in the import specification.
>
> To my mind option 4 is potentially interesting. There it might be
> possible
> to express "I want a 3.2 library that's greater or equal to 3.2.5." (I
> don't see a way to do that with the current syntax because I can't say
> "less than 3.3" only "less than or equal to 3.3".) If everyone
> everywhere
> agrees that the third number changes only when there are bug fixes
> (and no
> interface or contract changes) then that might be a way to verify that
> you
> link with a library that fixes some known defects while still accepting
> any newer library that honors the intended constraints. But that's a
> relatively narrow benefit I think, and I just don't know that it would
> see
> much use in practice.
It would be nice if one can really rely on version numbers by
themselves to guarantee compatibility. I really doubt this would be
the case since features and bugs are mostly the same thing: You might
use regexp v3.2.1.1.1 and then upgrade to v3.2.1.1.2 only to find that
a minor bug (that you relied on) was fixed!
> (Btw, maybe the fourth option is what you meant by "minor version." If
> so,
> my apologies. I always think of the second number as "minor" and the
> third
> number as "patch", and in my book only patch levels give you strong
> compatibility guarantees.)
I didn't say at which position a major version ends and a minor version
starts. What I meant was:
different major versions ~~ explicitly incompatible libraries
(e.g. different interfaces, contracts, ...)
different minor versions ~~ hopefully compatible libraries
(e.g. bug fixes, performance improvements, ...)
> I should point out that I *can* think of ways to make all of this much
> more useful, but I think that those ideas are currently out of scope
> for
> R6RS. For example, if you could test for the *presence* of a library at
> compile-time you could use that information in a cond-expand or some
> such
> thing to make interesting compile-time (and run-time) decisions. For
> instance, you might choose to implement regexp in terms of the
> Perl-compatible regexp library if it's availble, and in terms of the
> Scheme portable regexp library if it isn't.
There are other points in the design space for versioning. Debian's
packages immediately come to mind. In debian, the package itself and
its dependents *together* specify coexistence, conflicts, etc. For
example, you can say I want a perl-compatible-regexp version 5 or
better and the implementation can pick either a library built on top of
libpcre or a Scheme-based library (both of which satisfy
perl-compatible-regexp version 5). I don't think that this would
satisfy all the cool stuff one might imagine doing with libraries (more
of cond-expand below).
> Likewise, if you had access to
> a library's version number you might use it at compile time to provide
> work-arounds for known bugs in specific versions or you might use it at
> run-time to provide a diagnostic list of what versions of what
> libraries
> were included in a particular app. To me that kind of thing makes
> version
> numbers much more useful from within Scheme, but I just can't imagine
> the
> editors considering such things at this point.
Some implementations supporting R6RS may support an inspection or
interrogation compile-time primitives that a macro can use to ask the
system questions such as "is library foo available?", "what versions of
foo are there?", "which ones can be loaded, or not?", "let me test foo
to see if it has bug/feature X or not", and so on and so forth. I
believe (my guess here) is that these are not in R6RS because we just
don't know what they should be exactly! Once implementors start
experimenting with these things, a few SRFIs are written, best
practices are established, and the usefulness of these features are
demonstrated, then maybe such features would be standardized. That
said, I would like to hear what ideas you have when you said "I *can*
think of ways to make all of this much more useful" :-).
Aziz,,,
Received on Sat Nov 11 2006 - 00:52:29 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:00 UTC