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:08 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)
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 Marc Nieper-Wißkirchen 29 Sep 2020 16:00 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.