Email list hosting service & mailing list manager

define-library-alias Lassi Kortela (26 May 2020 13:34 UTC)
Re: define-library-alias Shiro Kawai (27 May 2020 00:07 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:01 UTC)
Re: define-library-alias Jim Rees (23 Sep 2020 12:51 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (23 Sep 2020 12:57 UTC)
Re: define-library-alias John Cowan (23 Sep 2020 21:44 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:10 UTC)
Re: define-library-alias Marc Nieper-Wißkirchen (26 Sep 2020 21:22 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:12 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:25 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:14 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:13 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:20 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:51 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:14 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:03 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:48 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:54 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:56 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:38 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:12 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:12 UTC)

Re: define-library-alias Lassi Kortela 27 May 2020 07:27 UTC

>     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