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:
  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

I have up-to-date versions of the reference implementation, but I haven't
released them to; 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:

Details of the three changes appear below, with rationales.

* 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

	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 ...).