>     Yes, in Chibi this is the meta-level module language. I can see how
>     this would be less elegant in implementations without a meta-level.

Good point.

>>                 This can also
>>                 be interpreted as "import the named library and
>>                 re-export all exported identifiers" (the name is
>>                 debatable), and if so, you can add more definitions
>>                 there to enhance the original library.  Pros are that
>>                 (1) it is clear that it's define-library level
>>                 meta-syntax and not an ordinary macro, and (2) in the
>>                 latter form, you can put additional definitions.   Cons:
>>                 it might be too flexible---too easy to write many
>>                 libraries that adds little something to existing
>>                 libraries, like what happened in the inheritance of OOP,

A further problem with extensible libraries is, what happens if the
original library is re-defined (reloaded) and adds or removes exports
compared to the old one?

There's another virtue to a simple define-library-alias: documentation
tools can directly tell the user that a library is an alias of another.
This is potentially very helpful for newcomers to Scheme.

With an aliased library, the whole library can be a simple indirection
to another library. There's no need to do extra work to walk the exports
and keep them in sync.

>                 Another option is to extend define-library syntax, e.g.
>                 (define-library (alias <library-name>)).

With this specific syntax, you could no longer create libraries whose
first library name part is `alias`.

>>        (define-library (scheme bitwise) (alias-for (srfi 151)))

> In terms of personal preference, I like alias-for and prohibit any other
> library declaration.

This is my favorite proposal so far (in addition to `define-library-alias`).

> Gauche has also export-all, but I started feeling ambivalent on it, when
> used in place of export.  It's good at the start of a new library when
> you don't know how the public API will be, but eventually you got sloppy
> to replace it with proper export, and exporting things that should be
> kept internal.

Exactly. Python had `from foo import *` all over the place and people
got sloppy. They eventually had to add a feature where each library can
specify which of its identifiers belong to the `*` set :)

I love the fact that Scheme doesn't have an export-all. You can then see
the public API at a glance by looking at the export forms in a
`define-library`, and it's reliable. Also makes it easy to write code
walkers to explore the public APIs.

>     There are several interpretations of export-all. [...] Probably
>     the most intuitive implementation if the set of
>     top-level definitions plus all imported bindings.

Since most libraries do (import (scheme base)), re-exporting all
imported bindings would add to the kind of namespace pollution that
Shiro warned about.

>     A variant which avoids this ambiguity is export from:
>
>        (define-library (scheme bitwise)
>          (import (srfi 151))
>          (export (from (srfi 151))))

This is reasonable and interesting. But is it overkill - is there a need
for a library to be a union of two or more libraries?

I'd still prefer an explicit list of exported symbols for each library
that is not strictly a simple alias of another.

>             However, the cons you mention swayed me.  I didn't want the
>             added flexibility or
>             discussions about resulting semantics.  What if you alias
>             multiple libraries? What
>             if you alias and then add some definitions?

+1

>
>             Also, this is more lightweight - there is only one library
>             object, which can be referred
>             to by either name in the library registry.

+1