Email list hosting service & mailing list manager

Settling the singular vs plural library names issue Lassi Kortela (02 Nov 2021 19:12 UTC)
(missing)
Re: [scheme-reports-wg2] Settling the singular vs plural library names issue Dr. Arne Babenhauserheide (02 Nov 2021 23:08 UTC)
Library name aesthetics Lassi Kortela (03 Nov 2021 07:55 UTC)
Re: [scheme-reports-wg2] Library name aesthetics Linas Vepstas (03 Nov 2021 17:47 UTC)
Re: [scheme-reports-wg2] Settling the singular vs plural library names issue Marc Nieper-Wißkirchen (21 Feb 2022 07:38 UTC)

Re: [scheme-reports-wg2] Settling the singular vs plural library names issue Marc Nieper-Wißkirchen 21 Feb 2022 07:38 UTC

Am Mo., 21. Feb. 2022 um 00:43 Uhr schrieb John Cowan <xxxxxx@ccil.org>:
>
>
>
> On Wed, Nov 3, 2021 at 3:13 AM Marc Nieper-Wißkirchen <xxxxxx@gmail.com> wrote:
>
>>
>> The SRFI library names are (seem to be) derived from SRFI 97, which is consistent with R6RS.  Thus we have two naming schemes, each of which is internally consistent:
>>
>> 1. (scheme SINGULAR) for R7RS-small and R7RS-large.
>
>
> This decision was taken by a vote of WG1, the R7RS-small committee, and cannot be undone now because WG1 is dissolved.  (I personally favored plural.)  I am reasonably confident that the WG1 members in the majority were aware of the R6RS convention and chose to break with it.  WG2 (R7RS-large) has so far chosen to follow the same convention as R7RS-small.
>
>> 2. (rnrs PLURAL) and (srfi :... PLURAL) for R6RS and its SRFI namespace.
>>
>> Aliases can be easily fit into this.  R7RS could support plural names under (rnrs PLURAL (7)) once a minimal versioning system is established; SRFI names could be singularized in, say, (srfi SINGULAR), i.e. without the SRFI 97 ":...".
>
>
> Aliasing is always a possibility in either R6 or R7, somewhat messily: you import the standard names and export your desired names.  That is why qua CCBW I have discouraged most discussions of post hoc renaming of either whole libraries or specific identifiers: if you want your own names, just provide them.  If your code is to be maintained by someone else, such name changes may annoy them.

With respect to individual identifier names, I can follow this
argument once a standard is adopted; R7RS-large, however, is still in
a state of flux.

With respect to library names, I don't see much of a problem with
aliasing if there is an agreement on interoperability with the R6RS
standard as well.