[r6rs-discuss] Libraries

From: MichaelL_at_frogware.com <MichaelL>
Date: Fri Nov 10 01:03:58 2006

(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?
Received on Fri Nov 10 2006 - 01:03:24 UTC