I'm done with the SRFI 13 & 14 specs. I have made two changes to the
char-set SRFI, and one change to both SRFIs:
1. CHAR-SET-INDEX is now CHAR-SET-REF.
2. Lowered minimum number of args to CHAR-SET= & CHAR-SET<= from two to zero.
3. Added a little explanatory text describing the spec notation.
I also made a few trivial changes to both sets of SRFIs, which I have
not bothered to list ("trivial" at the level of spell-checking and fixing
typos).
I have up-to-date versions of the reference implementation, but I haven't
released them to ftp.ai.mit.edu; I am going to make another careful pass
over the source -- testing and code review -- before posting them.
You can complain about these changes, but you better move fast, because I'm
notifying Mike that the specs are ready to go. That's why I've summarised the
changes below, to save you the trouble of reading the 135kb of spec text...
For the full documents, just click 'n view:
ftp://ftp.ai.mit.edu/people/shivers/srfi/13/string-lib.txt
ftp://ftp.ai.mit.edu/people/shivers/srfi/13/string-lib.html
ftp://ftp.ai.mit.edu/people/shivers/srfi/14/cset-lib.txt
ftp://ftp.ai.mit.edu/people/shivers/srfi/14/cset-lib.html
Details of the three changes appear below, with rationales.
-Olin
-------------------------------------------------------------------------------
* Changed the name of CHAR-SET-INDEX to CHAR-SET-REF.
char-set-index cset cursor -> char
is the wrong name for this function. The "-INDEX" lexeme is used in the
string SRFI for a search process (historical lineage from C/Unix, not
really such a great name, but there you are). More importantly, the proper
Schemish lexeme is "-REF", i.e.,
char-set-ref cset cursor -> char
by analogy with STRING-REF, VECTOR-REF, etc.
This issue will pop up when we get to hash tables, et al., so let's sync up
the convention now.
* Lowered the minimum number of args for CHAR-SET= and CHAR-SET<= from
two to zero.
Here is the rationale from the CHAR-SET= entry:
Rationale: transitive binary relations are generally extended to n-ary
relations in Scheme, which enables clearer, more concise code to be
written. While the zero-argument and one-argument cases will almost
certainly not arise in first-order uses of such relations, they may well
arise in higher-order cases or macro-generated code. E.g., consider
(apply char-set= cset-list)
This is well-defined if the list is empty or a singleton list. Hence
we extend these relations to any number of arguments. Implementors
have reported actual uses of n-ary relations in higher-order cases
allowing for fewer than two arguments. The way of Scheme is to handle the
general case; we provide the fully general extension.
A counter-argument to this extension is that R5RS's transitive binary
arithmetic relations (=, <, etc.) require at least two arguments, hence
this decision is a break with the prior convention -- although it is
at least one that is backwards-compatible.
* Added some text to explain the [ ] and ... notation in procedure signatures.
Here is the text:
Parameters given in square brackets are optional. Unless otherwise noted
in the text describing the procedure, any prefix of these optional
parameters may be supplied, from zero arguments to the full list. When a
procedure returns multiple values, this is shown by listing the return
values in square brackets, as well. So, for example, the procedure with
signature
halts? f [x init-store] -> [boolean integer]
would take one (F), two (F, X) or three (F, X, INPUT-STORE) input
parameters, and return two values, a boolean and an integer.
A parameter followed by "..." means zero-or-more elements. So the procedure
with the signature
sum-squares x ... -> number
takes zero or more arguments (X ...), while the procedure with signature
spell-check doc dict1 dict2 ... -> string-list
takes two required parameters (DOC and DICT1) and zero or more
optional parameters (DICT2 ...).