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
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
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)
|
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.