If we just want to define library aliases, we should contemplate
whether it is probably better to handle this outside the meta-syntax
of library declarations.

Remember that the mapping from library names to library definitions
(files) is not specified in R7RS but up to the implementation. In some
sense, every implementation has a registry that does the mapping (and
in most implementations, this registry is just the file system with
predefined search paths, etc.). This implementation-dependent registry
(to which we could add a standardized part) is a place where aliases
should be defined.

For example, in implementations where the filename of the library
definition depends on the library name, every alias would need a new
file, which just consists of one line. It would be more economical if
there was just one table (some sexp file) that holds the alias
mappings. Or, maybe, one file per directory. This could be
semi-standardized for those implementations that work on the file
system.

Marc

Am Mi., 27. Mai 2020 um 09:27 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> >     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