[r6rs-discuss] Libraries

From: MichaelL_at_frogware.com <MichaelL>
Date: Fri Nov 10 17:08:33 2006

> 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.)

> 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.

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.

(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 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. 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.

> Now regarding the library names being a single identifier vs. a list, I
> agree that a single identifier is simpler and there is no need as of
> right now for composite names. A naming convention might be needed
> though in order to disambiguate the different parts. For example, Perl
> (and others perhaps) uses :: as a name separator. A dash may not be
> ideal since it is used extensively in identifier names (for example,
> r6rs-hash-tables does not imply that there might be r6rs-hash-trees.
> r6rs::hash-tables or r6rs/hash-tables do a better job separating the
> names).

Yes, I think there are a few places in R6RS where new naming conventions
might be useful, and I agree that this might be one of them.

Thanks for your feedback. Very helpful.
Received on Fri Nov 10 2006 - 17:08:46 UTC