[HARLEQUIN][Common Lisp HyperSpec (TM)] [Previous][Up][Next]


Issue STRING-COERCION Writeup

Issue:          STRING-COERCION

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

Category: CLARIFICATION

Edit history: Version 1, 9-May-89 by Moon

Version 2, 9-May-89 by Pitman (editorial changes)

Problem description:

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.

Proposal (STRING-COERCION:MAKE-CONSISTENT):

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.

Examples:

(string-lessp #\a "B") => T

Rationale:

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

practice.

Current practice:

Symbolics Genera follows page 304 except for allowing additional

coercions. Symbolics Cloe follows page 299 except for not allowing

additional coercions.

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.

Performance impact:

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.

Benefits:

Consistency.

Esthetics:

Consistency.

Discussion:

None.


[Starting Points][Contents][Index][Symbols][Glossary][Issues]
Copyright 1996, The Harlequin Group Limited. All Rights Reserved.