Final changes to SRFIs 13 & 14 shivers@xxxxxx 23 Dec 2000 04:22 UTC
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 ...).