[r6rs-discuss] A different take on libraries

From: Arthur A. Gleckler <arthur>
Date: Wed Nov 15 01:42:05 2006

On Nov 14, 2006, at 9:43 PM, MichaelL_at_frogware.com wrote:

> With this approach, library syntax would change over time, but the
> changes
> would occur on top of a common foundation. And so the changes would be
> portable--or, at least, they'd have a fighting chance.

This is an excellent comment. I hope you'll submit something along
these lines formally. I've had similar worries about libraries in
the current draft, but hadn't been able to put my finger on what
worried me until I read your message.

I, too, would like to see the report offer a simple foundation on
which library systems of different styles could be built. The
current proposal is workable, but nails down too much and, in
particular, makes it unclear how interactive use of the language
could be made to work. I'd be much happier with a procedural layer
that I could use to build the current proposal or a completely
different library system.

Of course, there's nothing that says we can't have both the current
library proposal and a lower-level API just as we have syntax-case
and syntax-rules. Speaking of syntax-rules, it was frustrating that
Scheme had syntax-rules for years without a lower-level, more
powerful macro system like syntax-case. I'd hate to be in the same
situation with library systems until R7RS.

For comparison, MIT Scheme's analog to the library system has a way
to translate back and forth between "packages" and Scheme
environments, a system for maintaining a hierarchy of packages, and a
way to make variables share cells between packages. It's a powerful
system much like the current proposal. However, it differs in that
package names, imports, exports, and name changes are defined in
files completely separate from source files, which I like much
better. On the other hand, packages are defined statically in a way
that doesn't lend itself to interactive extension, something which
has frustrated me for years. (I've been too lazy to fix it,
though.) I'd hate for the same restriction to be made part of the
language itself.

The great thing about the MIT Scheme system, like many other
implementations, I'm sure, is that there is an underlying API which
can be used to extend the library system or to create another
system. The API is simple and easy to understand. These are the
primitives:

   (lexical-unreferenceable? environment symbol)

     Returns #T if looking up SYMBOL in ENVIRONMENT would cause an
error.
     Returns #F otherwise.

   (environment-link-name env1 env2 symbol)

     SYMBOL must be bound in ENV2. Creates a new binding for SYMBOL
in ENV1,
     such that the bindings in ENV1 and ENV2 share the same value cell.
     If SYMBOL is already bound in ENV1, the existing binding is
modified.

   (link-variables target-env target-name source-env source-name)

     Define a new binding for TARGET-NAME in TARGET-ENV, which shares
its
     value cell with the binding for SOURCE-NAME in SOURCE-ENV.
     SOURCE-NAME must be bound in SOURCE-ENV.

   (unbind-variable environment symbol)

     Unbind the variable SYMBOL in ENVIRONMENT.
     Returns #F if the variable was not previously bound. Returns #T
     otherwise.

This API might actually be too low level for R6RS, but it gives an
idea of the substrate upon which one library implementation is built.

I'd love to hear about the APIs used to build other Scheme
implementations' library systems. Maybe we can come up with a common
library language at a lower level to replace or supplement the
current proposal.

Thanks.
Received on Wed Nov 15 2006 - 01:41:49 UTC