Email list hosting service & mailing list manager

Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 04:28 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 05:50 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 06:26 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 06:46 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 06:59 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 07:17 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 07:35 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 08:31 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 09:01 UTC)
Re: Library names and sublibrary names John Cowan (22 Apr 2023 09:21 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 09:38 UTC)
Re: Library names and sublibrary names Lassi Kortela (22 Apr 2023 10:04 UTC)
Re: Library names and sublibrary names Marc Nieper-Wißkirchen (22 Apr 2023 10:17 UTC)

Re: Library names and sublibrary names Lassi Kortela 22 Apr 2023 10:04 UTC

> The use of ":" was discussed at length during the draft period of SRFI
> 97.  I didn't say that the mapping using ":" as a prefix is unnatural.

Apart from being arbitrary, ":" maps very unnaturally to file names.

> I don't think there is a need to break backward compatibility (with
> established schemes) gratuitously.

What matters is the whole "ecosystem". We install some Scheme
implementations and some library files. The former shall find the
latter. There is no established standard on this level, just special
cases for each implementation.

There's no sensible way to handle the mess without fully customizable
loaders which are at liberty to fully rewrite any library name. The ":"
prefix is not the only problem, and there are sure to be new unforeseen
problems in the future. RnRS can never solve this stuff; it'll be behind
the curve no matter how many hacks are standardized.

The requirement that every library name has at least one identifier
doesn't pose a problem for the above.