Am So., 27. Sept. 2020 um 03:44 Uhr schrieb Jim Rees <[email protected]>:
> 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.
