Settling the singular vs plural library names issue
17 views
Skip to first unread message
Lassi Kortela
Nov 2, 2021, 3:12:40 PM11/2/21
to srfi-d...@srfi.schemers.org, scheme-re...@googlegroups.com
Could we make an attempt to decide on either singular or plural for SRFI
and RnRS library names?
Below is an exhaustive survey of the current names. It shows that plural
is clearly winning: R7RS Small uses singular, but even in that standard
there are only two library names that clearly use singular where they
could use plural: (scheme char) and (scheme file). The other names are
either uncountable, or refer to something intrinsically singular such as
case-lambda, which is one specific operator.
R7RS Large adds several more singular library names, but since it's not
yet finalized, this might still change?
Apart from the singular vs plural habit, RnRS and especially R7RS favors
short library names, just a single word. Many of the current, non-RnRS
SRFI library names are quite long by comparison. Personally, I much
prefer the short names, but it would be nice to come to a consensus here
as well.
If we manage to make a decision, ideally we can synchronize the R7RS
Large and SRFI library names, adhering to a consistent style in each.
### R6RS names
arithmetic bitwise
arithmetic fixnums [plural]
arithmetic flonums [plural]
bytevectors [plural]
conditions [plural]
control
enums [plural]
eval
exceptions [plural]
files [plural]
hashtables [plural]
io ports [plural]
io simple
lists [plural]
mutable-pairs [plural]
mutable-strings [plural]
programs [plural]
r5rs
records inspection [plural]
records procedural [plural]
records syntactic [plural]
sorting
syntax-case
unicode
### R7RS Small names
base
case-lambda
char [singular]
complex
cxr
eval
file [singular]
inexact
lazy
load
process-context
r5rs
read
repl
time
write
### R7RS Large names vs equivalent SRFI names
SRFI 1 -- list -- lists [singular vs plural]
SRFI 14 -- charset -- char-sets [singular vs plural]
SRFI 41 -- stream -- streams [singular vs plural]
SRFI 101 -- rlist -- N/A [singular]
SRFI 111 -- box -- N/A [singular]
SRFI 113 -- set -- N/A [singular]
SRFI 115 -- regex -- regex
SRFI 117 -- list-queue -- list-queues [singular vs plural]
SRFI 121 -- generator -- N/A [singular]
SRFI 124 -- ephemeron -- N/A [singular]
SRFI 125 -- hash-table -- hashtables [singular vs plural]
SRFI 127 -- lseq -- lazy-sequences [plural]
SRFI 128 -- comparator -- N/A
SRFI 132 -- sort -- sorting
SRFI 133 -- vector -- vectors [singular vs plural]
SRFI 134 -- ideque -- N/A [singular]
SRFI 135 -- text -- N/A [singular]
SRFI 141 -- division -- integer-division
SRFI 143 -- fixnum -- fixnums [singular vs plural]
SRFI 144 -- flonum -- N/A [singular]
SRFI 146 -- mapping -- N/A [singular]
SRFI 151 -- bitwise -- bitwise-operations
SRFI 158 -- generator -- generators-and-accumulators [singular vs plural]
SRFI 159 -- show -- N/A
SRFI 160 -- vector -- N/A [singular]
### Non R7RS Large SRFI names
SRFI 0 cond-expand
SRFI 2 and-let*
SRFI 4 numeric-vectors [plural]
SRFI 5 let
SRFI 6 basic-string-ports [plural]
SRFI 8 receive
SRFI 9 records [plural]
SRFI 11 let-values
SRFI 13 strings [plural]
SRFI 15 fluid-let
SRFI 16 case-lambda
SRFI 17 generalized-set!
SRFI 18 multithreading
SRFI 19 time
SRFI 21 real-time-multithreading
SRFI 23 error
SRFI 25 multi-dimensional-arrays [plural]
SRFI 26 cut
SRFI 27 random-bits [plural]
SRFI 28 basic-format-strings [plural]
SRFI 29 localization
SRFI 31 rec
SRFI 34 exception-handling
SRFI 35 conditions [plural]
SRFI 37 args-fold
SRFI 38 with-shared-structure
SRFI 39 parameters [plural]
SRFI 42 eager-comprehensions [plural]
SRFI 43 vectors [plural]
SRFI 44 collections [plural]
SRFI 45 lazy
SRFI 46 syntax-rules
SRFI 47 arrays [plural]
SRFI 48 intermediate-format-strings [plural]
SRFI 51 rest-values [plural]
SRFI 54 cat
SRFI 57 records [plural]
SRFI 59 vicinities [plural]
SRFI 60 integer-bits [plural]
SRFI 61 cond
SRFI 63 arrays [plural]
SRFI 64 testing
SRFI 66 octet-vectors [plural]
SRFI 67 compare-procedures [plural]
SRFI 69 basic-hash-tables [plural]
SRFI 71 let
SRFI 74 blobs [plural]
SRFI 78 lightweight-testing
SRFI 86 mu-and-nu
SRFI 87 case
SRFI 95 sorting-and-merging
SRFI 98 os-environment-variables [plural]
SRFI 99 records [plural]
SRFI 126 r6rs-hashtables [plural]
SRFI 128 comparators [plural]
SRFI 129 titlecase
SRFI 130 string-cursors [plural]
SRFI 131 records [plural]
SRFI 145 assume
SRFI 152 strings [plural]
SRFI 156 predicate-combiners [plural]
SRFI 175 ascii
### Summary of clearly singular names
char [R7RS Small]
file [R7RS Small]
list [R7RS Large]
charset [R7RS Large]
stream [R7RS Large]
rlist [R7RS Large]
box [R7RS Large]
set [R7RS Large]
list-queue [R7RS Large]
generator [R7RS Large]
ephemeron [R7RS Large]
hash-table [R7RS Large]
vector [R7RS Large]
ideque [R7RS Large]
text [R7RS Large]
fixnum [R7RS Large]
flonum [R7RS Large]
mapping [R7RS Large]
generator [R7RS Large]
vector [R7RS Large]
### Summary of clearly plural names
arithmetic fixnums [R6RS]
arithmetic flonums [R6RS]
bytevectors [R6RS]
conditions [R6RS]
enums [R6RS]
exceptions [R6RS]
files [R6RS]
hashtables [R6RS]
io ports [R6RS]
lists [R6RS]
mutable-pairs [R6RS]
mutable-strings [R6RS]
programs [R6RS]
records inspection [R6RS]
records procedural [R6RS]
records syntactic [R6RS]
lists [SRFI 1]
char-sets [SRFI 14]
streams [SRFI 41]
list-queues [SRFI 117]
hashtables [SRFI 125]
lazy-sequences [SRFI 127]
vectors [SRFI 133]
fixnums [SRFI 143]
generators-and-accumulators [SRFI 158]
numeric-vectors [SRFI 4]
basic-string-ports [SRFI 6]
records [SRFI 9]
strings [SRFI 13]
multi-dimensional-arrays [SRFI 25]
random-bits [SRFI 27]
basic-format-strings [SRFI 28]
conditions [SRFI 35]
parameters [SRFI 39]
eager-comprehensions [SRFI 42]
vectors [SRFI 43]
collections [SRFI 44]
arrays [SRFI 47]
intermediate-format-strings [SRFI 48]
rest-values [SRFI 51]
records [SRFI 57]
vicinities [SRFI 59]
integer-bits [SRFI 60]
arrays [SRFI 63]
octet-vectors [SRFI 66]
compare-procedures [SRFI 67]
basic-hash-tables [SRFI 69]
blobs [SRFI 74]
os-environment-variables [SRFI 98]
records [SRFI 99]
r6rs-hashtables [SRFI 126]
comparators [SRFI 128]
string-cursors [SRFI 130]
records [SRFI 131]
strings [SRFI 152]
predicate-combiners [SRFI 156]
and RnRS library names?
Below is an exhaustive survey of the current names. It shows that plural
is clearly winning: R7RS Small uses singular, but even in that standard
there are only two library names that clearly use singular where they
could use plural: (scheme char) and (scheme file). The other names are
either uncountable, or refer to something intrinsically singular such as
case-lambda, which is one specific operator.
R7RS Large adds several more singular library names, but since it's not
yet finalized, this might still change?
Apart from the singular vs plural habit, RnRS and especially R7RS favors
short library names, just a single word. Many of the current, non-RnRS
SRFI library names are quite long by comparison. Personally, I much
prefer the short names, but it would be nice to come to a consensus here
as well.
If we manage to make a decision, ideally we can synchronize the R7RS
Large and SRFI library names, adhering to a consistent style in each.
### R6RS names
arithmetic bitwise
arithmetic fixnums [plural]
arithmetic flonums [plural]
bytevectors [plural]
conditions [plural]
control
enums [plural]
eval
exceptions [plural]
files [plural]
hashtables [plural]
io ports [plural]
io simple
lists [plural]
mutable-pairs [plural]
mutable-strings [plural]
programs [plural]
r5rs
records inspection [plural]
records procedural [plural]
records syntactic [plural]
sorting
syntax-case
unicode
### R7RS Small names
base
case-lambda
char [singular]
complex
cxr
eval
file [singular]
inexact
lazy
load
process-context
r5rs
read
repl
time
write
### R7RS Large names vs equivalent SRFI names
SRFI 1 -- list -- lists [singular vs plural]
SRFI 14 -- charset -- char-sets [singular vs plural]
SRFI 41 -- stream -- streams [singular vs plural]
SRFI 101 -- rlist -- N/A [singular]
SRFI 111 -- box -- N/A [singular]
SRFI 113 -- set -- N/A [singular]
SRFI 115 -- regex -- regex
SRFI 117 -- list-queue -- list-queues [singular vs plural]
SRFI 121 -- generator -- N/A [singular]
SRFI 124 -- ephemeron -- N/A [singular]
SRFI 125 -- hash-table -- hashtables [singular vs plural]
SRFI 127 -- lseq -- lazy-sequences [plural]
SRFI 128 -- comparator -- N/A
SRFI 132 -- sort -- sorting
SRFI 133 -- vector -- vectors [singular vs plural]
SRFI 134 -- ideque -- N/A [singular]
SRFI 135 -- text -- N/A [singular]
SRFI 141 -- division -- integer-division
SRFI 143 -- fixnum -- fixnums [singular vs plural]
SRFI 144 -- flonum -- N/A [singular]
SRFI 146 -- mapping -- N/A [singular]
SRFI 151 -- bitwise -- bitwise-operations
SRFI 158 -- generator -- generators-and-accumulators [singular vs plural]
SRFI 159 -- show -- N/A
SRFI 160 -- vector -- N/A [singular]
### Non R7RS Large SRFI names
SRFI 0 cond-expand
SRFI 2 and-let*
SRFI 4 numeric-vectors [plural]
SRFI 5 let
SRFI 6 basic-string-ports [plural]
SRFI 8 receive
SRFI 9 records [plural]
SRFI 11 let-values
SRFI 13 strings [plural]
SRFI 15 fluid-let
SRFI 16 case-lambda
SRFI 17 generalized-set!
SRFI 18 multithreading
SRFI 19 time
SRFI 21 real-time-multithreading
SRFI 23 error
SRFI 25 multi-dimensional-arrays [plural]
SRFI 26 cut
SRFI 27 random-bits [plural]
SRFI 28 basic-format-strings [plural]
SRFI 29 localization
SRFI 31 rec
SRFI 34 exception-handling
SRFI 35 conditions [plural]
SRFI 37 args-fold
SRFI 38 with-shared-structure
SRFI 39 parameters [plural]
SRFI 42 eager-comprehensions [plural]
SRFI 43 vectors [plural]
SRFI 44 collections [plural]
SRFI 45 lazy
SRFI 46 syntax-rules
SRFI 47 arrays [plural]
SRFI 48 intermediate-format-strings [plural]
SRFI 51 rest-values [plural]
SRFI 54 cat
SRFI 57 records [plural]
SRFI 59 vicinities [plural]
SRFI 60 integer-bits [plural]
SRFI 61 cond
SRFI 63 arrays [plural]
SRFI 64 testing
SRFI 66 octet-vectors [plural]
SRFI 67 compare-procedures [plural]
SRFI 69 basic-hash-tables [plural]
SRFI 71 let
SRFI 74 blobs [plural]
SRFI 78 lightweight-testing
SRFI 86 mu-and-nu
SRFI 87 case
SRFI 95 sorting-and-merging
SRFI 98 os-environment-variables [plural]
SRFI 99 records [plural]
SRFI 126 r6rs-hashtables [plural]
SRFI 128 comparators [plural]
SRFI 129 titlecase
SRFI 130 string-cursors [plural]
SRFI 131 records [plural]
SRFI 145 assume
SRFI 152 strings [plural]
SRFI 156 predicate-combiners [plural]
SRFI 175 ascii
### Summary of clearly singular names
char [R7RS Small]
file [R7RS Small]
list [R7RS Large]
charset [R7RS Large]
stream [R7RS Large]
rlist [R7RS Large]
box [R7RS Large]
set [R7RS Large]
list-queue [R7RS Large]
generator [R7RS Large]
ephemeron [R7RS Large]
hash-table [R7RS Large]
vector [R7RS Large]
ideque [R7RS Large]
text [R7RS Large]
fixnum [R7RS Large]
flonum [R7RS Large]
mapping [R7RS Large]
generator [R7RS Large]
vector [R7RS Large]
### Summary of clearly plural names
arithmetic fixnums [R6RS]
arithmetic flonums [R6RS]
bytevectors [R6RS]
conditions [R6RS]
enums [R6RS]
exceptions [R6RS]
files [R6RS]
hashtables [R6RS]
io ports [R6RS]
lists [R6RS]
mutable-pairs [R6RS]
mutable-strings [R6RS]
programs [R6RS]
records inspection [R6RS]
records procedural [R6RS]
records syntactic [R6RS]
lists [SRFI 1]
char-sets [SRFI 14]
streams [SRFI 41]
list-queues [SRFI 117]
hashtables [SRFI 125]
lazy-sequences [SRFI 127]
vectors [SRFI 133]
fixnums [SRFI 143]
generators-and-accumulators [SRFI 158]
numeric-vectors [SRFI 4]
basic-string-ports [SRFI 6]
records [SRFI 9]
strings [SRFI 13]
multi-dimensional-arrays [SRFI 25]
random-bits [SRFI 27]
basic-format-strings [SRFI 28]
conditions [SRFI 35]
parameters [SRFI 39]
eager-comprehensions [SRFI 42]
vectors [SRFI 43]
collections [SRFI 44]
arrays [SRFI 47]
intermediate-format-strings [SRFI 48]
rest-values [SRFI 51]
records [SRFI 57]
vicinities [SRFI 59]
integer-bits [SRFI 60]
arrays [SRFI 63]
octet-vectors [SRFI 66]
compare-procedures [SRFI 67]
basic-hash-tables [SRFI 69]
blobs [SRFI 74]
os-environment-variables [SRFI 98]
records [SRFI 99]
r6rs-hashtables [SRFI 126]
comparators [SRFI 128]
string-cursors [SRFI 130]
records [SRFI 131]
strings [SRFI 152]
predicate-combiners [SRFI 156]
Arthur A. Gleckler
Nov 2, 2021, 5:06:12 PM11/2/21
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
Good point. If we were voting, I would vote for singular and short, wherever possible.
Dr. Arne Babenhauserheide
Nov 2, 2021, 7:07:59 PM11/2/21
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org, Arthur A. Gleckler
"Arthur A. Gleckler" <a...@speechcode.com> writes:
> Good point. If we were voting, I would vote for singular and short, wherever possible.
The libraries in Guile are the following (with ice-9 being the canonical
prefix for guile-specifics):
ice-9 and-let-star
ice-9 arrays
ice-9 atomic
ice-9 binary-ports
ice-9 boot-9
ice-9 buffered-input
ice-9 calling
ice-9 command-line
ice-9 common-list
ice-9 compile-psyntax
ice-9 control
ice-9 copy-tree
ice-9 curried-definitions
ice-9 deprecated
ice-9 documentation
ice-9 eval
ice-9 eval-string
ice-9 exceptions
ice-9 expect
ice-9 fdes-finalizers
ice-9 format
ice-9 ftw
ice-9 futures
ice-9 gap-buffer
ice-9 getopt-long
ice-9 hash-table
ice-9 hcons
ice-9 history
ice-9 i18n
ice-9 iconv
ice-9 lineio
ice-9 list
ice-9 local-eval
ice-9 ls
ice-9 match
ice-9 match.upstream
ice-9 networking
ice-9 null
ice-9 occam-channel
ice-9 optargs
ice-9 peg
ice-9 peg cache
ice-9 peg codegen
ice-9 peg simplify-tree
ice-9 peg string-peg
ice-9 peg using-parsers
ice-9 poe
ice-9 poll
ice-9 popen
ice-9 ports
ice-9 posix
ice-9 pretty-print
ice-9 psyntax
ice-9 psyntax-pp
ice-9 q
ice-9 quasisyntax
ice-9 r5rs
ice-9 r6rs-libraries
ice-9 r7rs-libraries
ice-9 rdelim
ice-9 read
ice-9 receive
ice-9 regex
ice-9 runq
ice-9 rw
ice-9 safe
ice-9 safe-r5rs
ice-9 sandbox
ice-9 save-stack
ice-9 serialize
ice-9 session
ice-9 slib
ice-9 stack-catch
ice-9 streams
ice-9 string-fun
ice-9-style-repl
ice-9 suspendable-ports
ice-9 test
ice-9 textual-ports
ice-9 threads
ice-9 time
ice-9 top-repl
ice-9 unicode
ice-9 vlist
ice-9 weak-vector
language brainfuck compile-scheme
language brainfuck compile-tree-il
language brainfuck parse
language brainfuck spec
language bytecode
language bytecode spec
language cps
language cps closure-conversion
language cps compile-bytecode
language cps compile-js
language cps contification
language cps cse
language cps dce
language cps devirtualize-integers
language cps dump
language cps effects-analysis
language cps elide-arity-checks
language cps graphs
language cps intmap
language cps intset
language cps licm
language cps loop-instrumentation
language cps optimize
language cps peel-loops
language cps prune-top-level-scopes
language cps reify-primitives
language cps renumber
language cps rotate-loops
language cps self-references
language cps simplify
language cps slot-allocation
language cps spec
language cps specialize-numbers
language cps specialize-primcalls
language cps split-rec
language cps switch
language cps type-checks
language cps type-fold
language cps types
language cps utils
language cps verify
language cps with-cps
language ecmascript array
language ecmascript base
language ecmascript compile-tree-il
language ecmascript function
language ecmascript impl
language ecmascript parse
language ecmascript spec
language ecmascript tokenize
language elisp bindings
language elisp compile-tree-il
language elisp falias
language elisp lexer
language elisp parser
language elisp runtime
language elisp runtime function-slot
language elisp runtime value-slot
language elisp spec
language javascript
language javascript simplify
language javascript spec
language js-il
language js-il compile-javascript
language js-il inlining
language js-il spec
language scheme compile-tree-il
language scheme decompile-tree-il
language scheme spec
language tree-il
language tree-il analyze
language tree-il compile-bytecode
language tree-il compile-cps
language tree-il cps-primitives
language tree-il debug
language tree-il effects
language tree-il eta-expand
language tree-il fix-letrec
language tree-il inlinable-exports
language tree-il letrectify
language tree-il optimize
language tree-il peval
language tree-il primitives
language tree-il resolve-free-vars
language tree-il spec
language value spec
oop goops
oop goops accessors
oop goops active-slot
oop goops composite-slot
oop goops describe
oop goops internal
oop goops save
oop goops simple
oop goops stklos
rnrs
rnrs arithmetic bitwise
rnrs arithmetic fixnums
rnrs arithmetic flonums
rnrs base
rnrs bytevectors
rnrs conditions
rnrs control
rnrs enums
rnrs eval
rnrs exceptions
rnrs files
rnrs hashtables
rnrs io ports
rnrs io simple
rnrs lists
rnrs mutable-pairs
rnrs mutable-strings
rnrs programs
rnrs r5rs
rnrs records inspection
rnrs records procedural
rnrs records syntactic
rnrs sorting
rnrs syntax-case
rnrs unicode
scheme base
scheme case-lambda
scheme char
scheme complex
scheme cxr
scheme eval
scheme file
scheme inexact
scheme lazy
scheme load
scheme process-context
scheme r5rs
scheme read
scheme repl
scheme time
scheme write
scripts api-diff
scripts autofrisk
scripts compile
scripts disassemble
scripts display-commentary
scripts doc-snarf
scripts frisk
scripts generate-autoload
scripts help
scripts jslink
scripts lint
scripts list
scripts punify
scripts read-rfc822
scripts read-scheme-source
scripts read-text-outline
scripts scan-api
scripts snarf-check-and-output-texi
scripts snarf-guile-m4-docs
scripts summarize-guile-TODO
scripts use2dot
srfi srfi-1
srfi srfi-10
srfi srfi-11
srfi srfi-111
srfi srfi-13
srfi srfi-14
srfi srfi-16
srfi srfi-17
srfi srfi-171
srfi srfi-171 gnu
srfi srfi-171 meta
srfi srfi-18
srfi srfi-19
srfi srfi-2
srfi srfi-26
srfi srfi-27
srfi srfi-28
srfi srfi-31
srfi srfi-34
srfi srfi-35
srfi srfi-37
srfi srfi-38
srfi srfi-39
srfi srfi-4
srfi srfi-41
srfi srfi-42
srfi srfi-42 ec
srfi srfi-43
srfi srfi-45
srfi srfi-4 gnu
srfi srfi-6
srfi srfi-60
srfi srfi-64
srfi srfi-64 testing
srfi srfi-67
srfi srfi-67 compare
srfi srfi-69
srfi srfi-71
srfi srfi-8
srfi srfi-88
srfi srfi-9
srfi srfi-98
srfi srfi-9 gnu
statprof
sxml apply-templates
sxml fold
sxml match
sxml simple
sxml ssax
sxml ssax input-parse
sxml transform
sxml upstream assert
sxml upstream input-parse
sxml upstream SSAX
sxml upstream SXML-tree-trans
sxml upstream SXPath-old
sxml xpath
system base ck
system base compile
system base lalr
system base lalr.upstream
system base language
system base message
system base optimize
system base pmatch
system base syntax
system base target
system base types
system base types internal
system foreign
system foreign-library
system foreign-object
system repl command
system repl common
system repl coop-server
system repl debug
system repl describe
system repl error-handling
system repl repl
system repl server
system syntax
system vm assembler
system vm coverage
system vm debug
system vm disassembler
system vm dwarf
system vm elf
system vm frame
system vm inspect
system vm linker
system vm loader
system vm program
system vm trace
system vm traps
system vm trap-state
system vm vm
system xref
texinfo
texinfo docbook
texinfo html
texinfo indexing
texinfo plain-text
texinfo reflection
texinfo serialize
texinfo string-utils
web client
web http
web request
web response
web server
web server http
web uri
Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de
Arthur A. Gleckler
Nov 2, 2021, 7:10:13 PM11/2/21
to Dr. Arne Babenhauserheide, scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
On Tue, Nov 2, 2021 at 4:07 PM Dr. Arne Babenhauserheide <arne...@web.de> wrote:
Are there other libraries — those from other schemes?
Also a good point.
Perhaps the consistency ship has sailed, and we should just find a way of creating aliases. Or would that create even more confusion?
John Cowan
Nov 2, 2021, 7:17:05 PM11/2/21
to scheme-re...@googlegroups.com
We have singular names in R7RS-small because WG1 voted for that rule. (I favored plural names myself, but vox populi vox Dei.) We have singular names in R7RS-large because it didn't make sense to make them incompatible with R7RS-small.
--
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 scheme-reports-...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/a5bf4a76-6f9a-2213-c41b-129cc5206ad5%40lassi.io.
Arthur A. Gleckler
Nov 2, 2021, 7:27:46 PM11/2/21
to scheme-re...@googlegroups.com
On Tue, Nov 2, 2021 at 4:17 PM John Cowan <co...@ccil.org> wrote:
We have singular names in R7RS-small because WG1 voted for that rule.
Ah, sorry. I forgot about that vote.
Marc Nieper-Wißkirchen
Nov 3, 2021, 3:13:02 AM11/3/21
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
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.
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 ":...".
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).
Lassi Kortela
Nov 3, 2021, 3:55:02 AM11/3/21
to srfi-d...@srfi.schemers.org, scheme-re...@googlegroups.com
> 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.
> 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).
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]
basic-hash-tables [SRFI 69]
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.
Linas Vepstas
Nov 3, 2021, 1:47:01 PM11/3/21
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
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
--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.
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
> --
> 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 scheme-reports-...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/scheme-reports-wg2/94851071-24d9-39aa-578d-b520b64f7c77%40lassi.io.
> 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 scheme-reports-...@googlegroups.com.
--
Patrick: Are they laughing at us?
Sponge Bob: No, Patrick, they are laughing next to us.
John Cowan
Feb 20, 2022, 6:43:02 PM2/20/22
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
On Wed, Nov 3, 2021 at 3:13 AM Marc Nieper-Wißkirchen <marc....@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.
Marc Nieper-Wißkirchen
Feb 21, 2022, 2:38:37 AM2/21/22
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
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.
John Cowan
Feb 21, 2022, 3:02:47 PM2/21/22
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
On Mon, Feb 21, 2022 at 2:38 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
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.
It is most misleading to say so. SRFIs, whether adopted as part of Large or not, can be changed only by errata or by PFNs. Errata of course can go on as long as anyone is still interested: an erratum for C11 could be issued today, but we do not say that C11 is in a state of flux because of that. A PFN can be incorporated into Large by a vote of WG2 as long as the Committee is still active, but there are severe limits (which Arthur could explain better than I) on how much change a PFN can actually introduce. (Daphne is, I think, urging us to adopt a third process, or perhaps to adopt a non-SRFI process for new proposals: I don't know which yet.) It is of course true that there are many proposals which have not been voted into Large, and they are partially in flux: the specific proposals are not yet chosen and neither are their names.
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.
I do not know what "agreement on interoperability" means in this context.
Marc Nieper-Wißkirchen
Feb 21, 2022, 4:33:16 PM2/21/22
to scheme-re...@googlegroups.com, srfi-d...@srfi.schemers.org
Am Mo., 21. Feb. 2022 um 21:02 Uhr schrieb John Cowan <co...@ccil.org>:
>
>
>
> On Mon, Feb 21, 2022 at 2:38 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
>> 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.
>
>
> It is most misleading to say so. SRFIs, whether adopted as part of Large or not, can be changed only by errata or by PFNs. Errata of course can go on as long as anyone is still interested: an erratum for C11 could be issued today, but we do not say that C11 is in a state of flux because of that. A PFN can be incorporated into Large by a vote of WG2 as long as the Committee is still active, but there are severe limits (which Arthur could explain better than I) on how much change a PFN can actually introduce. (Daphne is, I think, urging us to adopt a third process, or perhaps to adopt a non-SRFI process for new proposals: I don't know which yet.) It is of course true that there are many proposals which have not been voted into Large, and they are partially in flux: the specific proposals are not yet chosen and neither are their names.
As far as I see it before the Steering Committee is asked to endorse
>
>
>
> On Mon, Feb 21, 2022 at 2:38 AM Marc Nieper-Wißkirchen <marc....@gmail.com> wrote:
>
>> 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.
>
>
> It is most misleading to say so. SRFIs, whether adopted as part of Large or not, can be changed only by errata or by PFNs. Errata of course can go on as long as anyone is still interested: an erratum for C11 could be issued today, but we do not say that C11 is in a state of flux because of that. A PFN can be incorporated into Large by a vote of WG2 as long as the Committee is still active, but there are severe limits (which Arthur could explain better than I) on how much change a PFN can actually introduce. (Daphne is, I think, urging us to adopt a third process, or perhaps to adopt a non-SRFI process for new proposals: I don't know which yet.) It is of course true that there are many proposals which have not been voted into Large, and they are partially in flux: the specific proposals are not yet chosen and neither are their names.
the final product, any change can still, in principle, be made.
Nothing prevents us to vote, say, some hypothetical SRFI 301 into
R7RS-large, replacing SRFI 1 in some incompatible way.
>> 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.
>
>
> I do not know what "agreement on interoperability" means in this context.
practical, also a valid R7RS-large program so that maintaining a
codebase that works both in R7RS-large and in R6RS implementations is
possible. Think of C and C++.
Reply all
Reply to author
Forward
0 new messages