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