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 Marc Nieper-Wißkirchen 22 Apr 2023 10:17 UTC

Am Sa., 22. Apr. 2023 um 12:04 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > 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.

If the number object represented by "123" and the identifier
represented by ":123" are to be considered interchangeably (at least
in some circumstances), both should map to the same path, which could
mean a path component of "123".

The point is that there is no obvious embedding of the union of the
set of exact nonnegative integers and the set of symbols in the set of
strings (or allowed pathname components).

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

I agree with what you say about library loaders (or package installers).

I disagree with rewriting library names.  The library name is part of
the library's API and identifies (together with the version, if any)
the library uniquely.  Any mapping that needs to be done has to happen
on the level of the mapping from (abstract) library names (given by
compounds of symbols/numbers) and pathnames (or capabilities).  But
you probably meant this anyway.