define-library-alias Lassi Kortela (26 May 2020 13:34 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 00:08 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 02:07 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 02:08 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (23 Sep 2020 06:02 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 12:52 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (23 Sep 2020 12:58 UTC)
Re: define-library-alias John Cowan (23 Sep 2020 21:45 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (24 Sep 2020 05:53 UTC)
Re: define-library-alias John Cowan (25 Sep 2020 21:27 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 07:44 UTC)
Re: define-library-alias Jim Rees (26 Sep 2020 21:11 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 21:23 UTC)
Re: define-library-alias Jim Rees (27 Sep 2020 01:44 UTC)
Re: define-library-alias John Cowan (27 Sep 2020 17:49 UTC)
Re: define-library-alias Arthur A. Gleckler (27 Sep 2020 18:16 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (29 Sep 2020 16:13 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (30 Sep 2020 07:08 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (29 Sep 2020 16:00 UTC)
Re: define-library-alias Jim Rees (26 Sep 2020 01:05 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 07:49 UTC)
Re: define-library-alias Alex Shinn (27 May 2020 00:35 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 01:30 UTC)
Re: define-library-alias Alex Shinn (27 May 2020 03:26 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 04:09 UTC)
Re: define-library-alias Lassi Kortela (27 May 2020 07:27 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (27 May 2020 07:53 UTC)
Re: define-library-alias Lassi Kortela (27 May 2020 07:57 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (27 May 2020 08:05 UTC)
SCHEME_PATH and library lookup metadata files Lassi Kortela (27 May 2020 08:15 UTC)
Re: SCHEME_PATH and library lookup metadata files Marc Nieper-Wißkirchen (27 May 2020 08:24 UTC)
Re: SCHEME_PATH and library lookup metadata files Lassi Kortela (27 May 2020 09:04 UTC)
Reader flags to indicate different kinds of files Lassi Kortela (27 May 2020 09:14 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (27 May 2020 09:21 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (27 May 2020 09:51 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (27 May 2020 10:21 UTC)
Re: Reader flags to indicate different kinds of files Per Bothner (27 May 2020 14:42 UTC)
Re: Reader flags to indicate different kinds of files John Cowan (27 May 2020 17:46 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (27 May 2020 20:16 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 16:03 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (29 May 2020 17:03 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 17:09 UTC)
Re: Reader flags to indicate different kinds of files Marc Nieper-Wißkirchen (29 May 2020 17:52 UTC)
Data vs metadata distinction Lassi Kortela (29 May 2020 17:59 UTC)
Re: Data vs metadata distinction Marc Nieper-Wißkirchen (02 Jun 2020 09:43 UTC)
Re: Reader flags to indicate different kinds of files John Cowan (29 May 2020 17:15 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 17:26 UTC)
Re: Reader flags to indicate different kinds of files Lassi Kortela (29 May 2020 17:41 UTC)
Re: Reader flags to indicate different kinds of files John Cowan (29 May 2020 18:04 UTC)
Re: SCHEME_PATH and library lookup metadata files Marc Nieper-Wißkirchen (27 May 2020 09:26 UTC)
Scheme filename extensions Lassi Kortela (27 May 2020 09:40 UTC)
Re: Scheme filename extensions Marc Nieper-Wißkirchen (27 May 2020 09:49 UTC)
Re: Scheme filename extensions Marc Nieper-Wißkirchen (27 May 2020 09:51 UTC)
Re: Scheme filename extensions Lassi Kortela (27 May 2020 10:21 UTC)
Re: Scheme filename extensions Alex Shinn (27 May 2020 09:55 UTC)
Re: Scheme filename extensions Lassi Kortela (27 May 2020 10:30 UTC)
Library lookup metadata file Lassi Kortela (27 May 2020 10:32 UTC)
Re: Scheme filename extensions John Cowan (28 May 2020 17:30 UTC)
Re: define-library-alias Alex Shinn (04 Jun 2020 14:57 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (04 Jun 2020 15:31 UTC)
Re: define-library-alias Marc Feeley (04 Jun 2020 15:37 UTC)
Re: define-library-alias Lassi Kortela (04 Jun 2020 15:39 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (21 Sep 2020 06:13 UTC)
Re: define-library-alias Lassi Kortela (22 Sep 2020 16:05 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (22 Sep 2020 16:13 UTC)
Re: define-library-alias Lassi Kortela (22 Sep 2020 16:41 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (22 Sep 2020 17:13 UTC)

Re: define-library-alias Marc Nieper-Wißkirchen 27 May 2020 07:53 UTC

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