References: Strings (pp299-304),
STRING= (p300), STRING-EQUAL (p301), STRING< (p301),
STRING> (p301), STRING<= (p301), STRING>= (p301),
STRING/= (p301), STRING-LESSP (p302), STRING-GREATERP (p302),
STRING-NOT-GREATERP (p302), STRING-NOT-LESSP (p302),
STRING-NOT-EQUAL (p302), STRING-TRIM (p302), STRING-LEFT-TRIM (p302),
STRING-RIGHT-TRIM (p302), STRING-UPCASE (p303), STRING-DOWNCASE (p303),
and STRING-CAPITALIZE (p303).
Related issues: none
Edit history: Version 1, 9-May-89 by Moon
Version 2, 9-May-89 by Pitman (editorial changes)
CLtL is inconsistent about the argument coercion performed by the
referenced functions. Page 299 says that the <string> argument can
be either a symbol or a string. Page 304 says that these functions
effectively call the STRING function, thus accepting a symbol,
a string, or a character.
Neither page lists the set of affected functions explicitly.
Page 304 says that if any other data type is used, an error is
signalled. But some implementations allow other types, such as
pathnames, to be coerced to strings, which page 299 appears to allow
but page 304 appears to forbid. In some implementations these
coercions are under user control via methods for a generic function.
Specify that the referenced functions perform coercion identical to
the action of the STRING function.
Specify that the STRING function can perform additional implementation
dependent coercions. In all cases the returned value is of type STRING.
Only in the case where no coercion is defined is the STRING function
required to signal an error; in that case, the error is of type TYPE-ERROR.
(string-lessp #\a "B") => T
Our choices are to make the coercion identical to the STRING function,
identical to the COERCE function, or different from both of them. The
COERCE function won't coerce non-null symbols to strings, so it is out.
Being consistent with the STRING function seems better than inventing
yet another set of string coercion rules. Removing the ability for the
STRING function to coerce characters to strings would be an incompatible
change, so instead we clarify that the other functions have that ability.
Allowing additional coercions is harmless and consistent with current
Symbolics Genera follows page 304 except for allowing additional
coercions. Symbolics Cloe follows page 299 except for not allowing
Cost to Implementors:
Small changes to eighteen functions.
Cost to Users:
None, this is upward-compatible.
Cost of non-adoption:
Inconsistency and confusion about what coercions are allowed.
None. If these things have to accept symbols, accepting characters
too can't make much difference. The implementation of character
arguments to string functions might cons a string, but this has no
performance impact on programs that don't use the feature.