Am So., 27. Sept. 2020 um 03:44 Uhr schrieb Jim Rees <xxxxxx@gmail.com>:

> Maybe we should only communicate via well-written scheme test-cases from now on. ;-)

The problem is that whenever I type examples (without actually running
them), I usually tend to integrate a silly bug.

> So, this all winds back to your concern that we need to be mindful of the different behaviors of different approaches to library composition or aliasing.   Personally, I think in this case no contracts are being broken.   If you have to use datum->syntax to detect the differences (and minimal collaboration from the libraries involved to expose their internal contexts), then nobody should be able to claim foul when a library is re-composed in a different way.    If you have a plausible real-world counter-example, I'd love to see it.

I agree, more or less. My point was the implementation. We should be
aware of the subtle differences in the implementation (and try to
choose the best one) as we don't know what other implications
imprecise specifications will have in the future.

> Unwinding further, you asked my opinion about define-library-alias vs. alternative library composition declarations:
>
> I agree with you that define-library-alias is fundamentally different from any of the composition options, though mainly only in ways of efficiency, not semantics.    I agree with John that a representation of library aliases is not something we can really standardize without first establishing an additional standard that talks about files, directories, and perhaps a place to put the alias table(s) you suggested.   There's not a lot of benefit to replacing one file that imports and re-exports a bunch of ids vs. a file that says it aliases another library -- in both cases the file still has to be read (and in an auto-dependency checking system, re-read or at least stat'ed if you trust modification timestamps) -- other than semantic clarity.   Your table method is more likely to produce an efficiency benefit.   In the end, I am in favor of the concept that the mapping from library-name to library can be many-to-one.
>
> Independent of the application of library aliasing, it would be nice to have a *-ish export feature.  (srfi 160) being a composition of (srfi 160 u8), (srfi 160 s8), (srfi 160 f32), ... comes to mind as a use case as the list of ids there is very long, and when implementations support additional numeric formats (like I play with), it really helps with maintenance.
>
> I like my export-from declaration (accepts arbitrary import specs, and only re-exports, does not import) because if I also want to import the same ids, I can do that separately.
>
> export-all is not my favorite as it seems to be useful in only a very limited set of cases.   If any local code is to be added, you can't have un-exported helper functions/macros.

I agree.

> extends  -- either it can only be used on a single library (single inheritance) or if can be used more than once, it's just a version of export-from or (export (from ...) that cannot apply renamings or subsetting to its arguments.    I highly prefer the concept of composition over inheritance/extension.

I would call it "extend" because "import" and "export" also seem to be
imperatives. In any case, such new import sets/export specs should
allow the existing modifiers only/prefix/rename/... as much as
possible.