John, I don't think that what you have commented about is related to what we have been discussing (unless I misunderstood you). What I have been discussing with Jim lately is the following: If a library exports an identifier `foo', one can access all (not renamed) identifiers that are defined at the top-level of the library, namely through (datum->syntax #'foo top-level-identifier-name) or a similar construction for the given macro system that allows unhygienic bindings. Therefore, not only the set exported identifiers but also the top-level environment of a library is an observable quantity. And the latter can behave quite differently: (1) One library may completely alias another one. In this case, the top-level environments and the set of exports are the same. (2) One library may extend (possibly trivial) another library. In this case, the top-level environments are disjoint. (3) One library adds the exports of another library to its own exports without importing the other library itself. In this case, the top-level environments are again disjoint. Am Mi., 23. Sept. 2020 um 23:45 Uhr schrieb John Cowan <xxxxxx@ccil.org>: > > Just a reminder that the define-library language is not Scheme, and in particular, macro expansion can neither create a define-library nor can it create a clause or list of clauses. (Of course macro expansion is done in the *body* of a begin-clause, because that is Scheme.) > > On Wed, Sep 23, 2020 at 8:58 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: >> >> Am Mi., 23. Sept. 2020 um 14:52 Uhr schrieb Jim Rees <xxxxxx@gmail.com>: >> > >> > On Wed, Sep 23, 2020 at 2:02 AM Marc Nieper-Wißkirchen <xxxxxx@nieper-wisskirchen.de> wrote: >> >> >> >> >> >> What do you exactly mean by "does not contaminate the local >> >> environment"? That the hypothetical library body of, in this example, >> >> (scheme list) does not see the bindings of (srfi 1)? >> > >> > >> > Exactly. I wanted to isolate the effects of export-from and import from each other. >> >> I would suggest merging this with `define-library-alias', which would >> then become `define-library-composition'. What do you think? >> >> In any case, this discussion shows that one shouldn't add extensions >> to the module language lightly as the semantics can be surprising when >> low-level macros and unhygiene is involved.
