Email list hosting service & mailing list manager

Settling the singular vs plural library names issue Lassi Kortela (02 Nov 2021 19:12 UTC)
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] Library name aesthetics Linas Vepstas 03 Nov 2021 17:46 UTC

I suggest "rt-threads" for the second threads, since real-time is
deeply and fundamentally different, and should not be confused with
the ordinary case.

I suggest "comprehensions" instead of "ec" because ec is a bit too
short. All of the other shortened names correspond to ideas present in
many programming languages, and are thus more-or-less readily
understandable. "ec" is not.  Sometimes, even the smart programmer
needs a reminder of what something stands for.

-- linas

On Wed, Nov 3, 2021 at 2:55 AM Lassi Kortela <> wrote:
> > 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 ":...".
> >
> > Alternatively, R7RS-large could add plural aliases to its (scheme ...)
> > namespace for compatibility with R6RS and thus paving a way for a
> > possible later deprecation of the singular names in favor of consistency
> > (with earlier standards).
> Interesting ideas.
> Apart from the singular/plural distinction, there's quite a lot of
> stylistic difference as well. It would be nice to arrive at a consistent
> aesthetic (while retaining backward compatible aliases, as you suggest).
> In particular, the following library names from SRFI 97 are very
> verbose, probably without adding much clarity. Is "sorting-and-merging"
> really clearer than "sort"? Rob Pike railed against "variables whose
> names are small essays on their use" in a similar vein, and practical
> Scheme programs' import lists tend to get quite long anyway.
> basic-string-ports [SRFI 6]
> generalized-set! [SRFI 17]
> multithreading [SRFI 18]
> real-time-multithreading [SRFI 21]
> multi-dimensional-arrays [SRFI 25]
> basic-format-strings [SRFI 28]
> with-shared-structure [SRFI 38]
> eager-comprehensions [SRFI 42]
> intermediate-format-strings [SRFI 48]
> compare-procedures [SRFI 67]
> basic-hash-tables [SRFI 69]
> lightweight-testing [SRFI 78]
> sorting-and-merging [SRFI 95]
> I would prefer the following names, which are more in line with the
> brevity of RnRS names, and especially R7RS:
> string-ports
> set!
> threads
> threads [a second time; the SRFI number disambiguates them]
> format
> shared
> ec [all the identifiers have `ec` in their names]
> format [a second time]
> compare [all the identifiers have `compare` in their names]
> hashtables
> testing
> sorting
> One could argue in detail about "thread" vs "threads" vs "threading".
> R6RS uses sub-libraries in a way that R7RS would consider gratuitous:
> arithmetic bitwise
> arithmetic fixnums
> arithmetic flonums
> io ports
> io simple
> but there are so few of them that it's probably not much of an issue.
> --
> You received this message because you are subscribed to the Google Groups "scheme-reports-wg2" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to
> To view this discussion on the web visit

Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.