Issue: STRING-COERCION (version 2)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

This is a new issue.  This issue seems sufficiently simple and
noncontroversial that I would like to see it on the agenda for the June
X3J13 meeting.  Let's use the cleanup subcommittee to test the assertion
that this is a simple and noncontroversial issue.  If it's
controversial, let's just drop it, otherwise let's give X3J13 a chance
to vote for or against it.

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.