[r6rs-discuss] Libraries

[MichaelL at frogware.com]

(I was interested in feedback on the following before submitting a formal 
comment.)

I was thinking about libraries, and I have some questions and comments.

First, when I think about actual usage it appears to me that multi-part 
library names and library versions are something of a gimmick. More to the 
point, they seem to me to be a gimmick that could hurt rather than help 
portability. So my question is: are they actually useful?

Multi-part library names would be useful if, for example, each part of the 
name mapped to something in the file system. That doesn't, however, appear 
to be the case. For example, R6RS defines the library "r6rs" as a 
composite of most of the libraries in the report. Thus "r6rs" in a name 
like "(r6rs lists)" doesn't seem to refer to, say,  a directory or 
namespace but rather to an identifier that happens to be a list. Why 
wouldn't "r6rs-lists" be just as good?

I raise the point because in the examples in section 6.4 on pages 25-26 of 
5.91the multi-part names actually make the code more difficult to read. 
Look, for example, at the code at the bottom of page 26 in the left 
column:

        (library (my-helpers values-stuff) 
                (export mvlet) 
                (import r6rs (for (my-helpers id-stuff) expand))

        ...

        (library let-div 
                (export let-div) 
                (import r6rs (my-helpers values-stuff)) 

        ...

Does having a list-valued name really help anything? Compare that to this:

        (library my-helpers-values-stuff
                (export mvlet) 
                (import r6rs (for my-helpers-id-stuff expand))

        ...

        (library let-div 
                (export let-div) 
                (import r6rs my-helpers-values-stuff) 

        ...

I'm not saying that those are better names, just that it takes less effort 
to understand what's going on (especially in the "(for ... expand)" 
example). Of course, given the complexity of what can happen during 
imports--prefixing, renaming, etc--examples can actually be much worse.

I think version numbers are somewhat similar. At first blush having 
version numbers sounds great--but then how do you actually use them? You 
can restrict an import to certain version numbers... and then what 
happens? It seems like the only thing you can really do is have an import 
fail if an appropriate version isn't present. Well, you could just about 
do that by putting a version number into the symbol naming the library.

And guess what--that's what r6rs does for its own libraries! (That's the 
"6" in "r6rs"!)

I'm not saying that it's impossible to come up with some way to use the 
feature. I'm asking about whether or not we gain enough from the use to 
merit the additional complexity.

My portability concern is that implementations will be tempted to use 
multi-part names and version numbers because, well, they seem like they 
should be useful. For example, it seems quite natural to try to map a 
multi-part name to the file system. But such issues are avoided by the 
spec meaning that it's all too likely different implementations would do 
different things. Libraries are the single most important part of R6RS and 
it would be a shame if they opened a new portability problem.

So my recommendation would be to drop multi-part names and version numbers 
in R6RS and go (initially) with a simpler mechanism. If use warrants it 
would still be possible to add those features in R7RS, since one symbol 
names are a subset of the current proposal. (This would mean that the r6rs 
names would be things like r6rs-list, r6rs-hash-tables, 
r6rs-records-procedural, r6rs-records-explicit, etc.)

Thoughts? Counter-examples?