[r6rs-discuss] Libraries

[MichaelL at frogware.com]

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