Thank you for your work Wolfgang. And I need additional information from
you:
1. As for SRFI 146 issues, it says:"Any implementation shall also
provide the library (srfi 146 hash) which implements essentially the
same interface (see below) as (srfi 146) but requires comparators to
provide a hash function instead of an ordering predicate, unless the
equality predicate of the comparator is eq?, eqv?, equal?, string=?, or
string-ci=?."
This means including (srfi 146), (srfi 146 hash) should be provided
additionally, right? If so, I regard it as an exception and SRFI 261
shouldn't name it. And I'll left it in omitted srfis. What do you& the
SRFI261 think?
2. As for SRFI 153 issues, you're right. I forget what silly thing I
did. And I'll correct it to ordered-sets. This is Scheme, not C, naming
a library too briefly is ridiculous,LOL. (Here's a joke)
3. As for SRFI 196, you're right.
4. As for SRFI 203, you're right. I rename it to picture-language.
5. As for SRFI 219,221,253, you're right.
6. As for SRFI 251, well, I don't have good idea... How about
'body-mixtures"?
I will continually process your remaining comments in the next few days,
after I finish reading Daphne's points.
Thank you again Wolfgang.
在 10/8/25 12:33, Wolfgang Corcoran-Mathe 写道:
Some of these names are confusing or ignore the terminology used in
the SRFI itself:
* SRFI 146 provides two different libraries, (srfi 146) &
(srfi 146 hash), but is just called "mappings".
* SRFI 153 provides*ordered* sets ("osets", in the SRFI), but is
given the name "sets". This is vague.
* 196 should be called "ranges", not "range object".
* "pictures" is too general a name for SRFI 203, which implements a
specific picture-drawing language from the SICP textbook.
* Simple mistakes: SRFI 219 is called "define", & SRFI 221 is called
"higher-order-lambda". SRFI 219 is the higher-order lambda SRFI &
is unrelated to 221 ("Generator/accumulator sub-library").
253 is called "type-chec[k]ing".
* Some names, like "mixing-definitions-and-expressions", are
needlessly long. Finding short names is notoriously tough, but
standardizing a long, ugly name for the sake of standardizing
*some* name is a bad idea.
There is also the problem of the omitted SRFIs, which Daphne has
said a great deal about.
Another problem related to Daphne's points is more subtle: Not all
SRFIs state that everything in them should be provided by a single
library. An especially problematic example is SRFI 146, which exports
the same identifiers from different libraries. But the problem is
general: someone might split an implementation of SRFI 189 into (srfi
:189 maybe) and (srfi :189 either), for example. The SRFI itself,
like many others, doesn't state an opinion on the matter. I'm not
sure I like the idea of imposing a monolithic Scheme library name
on SRFIs whose authors didn't give a specific library structure.
I appreciate the work it took to come up with all of these names,
but I also think naming is hard. It requires a lot of thought &
careful reading of every (!) SRFI library & SRFI*sublibrary* you
intend to name. The name should reflect the SRFI's language & its
author's intentions, not just its title or abstract.
My preference is for SRFI 261 to stick to library-name formats & to
leave the names themselves alone.
