Issue: COERCE-INCOMPLETE (Version 2)

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

I oppose this proposal.  I think what it's trying to do fundamentally
cannot work.  I would characterize what it's trying to do as trying to
bring as many one-input-one-output functions under the umbrella of
COERCE as possible.  (Even worse of course is cases like ACCESSIBLE-SYMBOL
where the function has two inputs, but you're getting the second input
 from a special variable.)

type-specifiers are supposed to be names for sets of objects.  Two
type-specifiers that designate the same set of objects are supposed to
be usable interchangeably, except when their equivalence is uncomputable
because of SATISFIES.  However, when we start making up new
type-specifier names as a back-door way (or an elegant way, depending on
one's point of view) to tell COERCE what internal function to call, we
run into two problems:

First, it isn't clear whether one can call COERCE with a type-specifier
that designates the same set of objects as one of the builtin type
specifiers, and get the same result.  Suppose I define my own type
specifier that designates the same set of objects as INTEGER-STRING, for
example.  Are the second and third arguments to COERCE really
type-specifiers, or are they really just specially-recognized symbols
that are made to resemble type-specifiers to make them easier to
remember?

Second, and I think this is an even worse problem, when x is a subtype
of y, Kent sometimes calls for an x coercion which is not compatible with
the y coercion.  For example, the proposal appears to say that
(COERCE 65 'STRING) => "A" but (COERCE 65 'INTEGER-STRING) => "65", even
though INTEGER-STRING is a subtype of STRING.

I think the proposal is a good try, but I think the original idea of
COERCE was not well-founded enough to survive such addition of features.

Kent wanted line by line comments, I suppose I can do that too.
   1. CHARACTER <-> STRING
string -> character already exists, I don't see any harm in adding the inverse,
especially since the function STRING already does it.
   2. CHAR-CODE <-> CHARACTER
   3. CHAR-INT <-> CHARACTER
   7. CHAR-CODE <-> STRING
   8. CHAR-INT <-> STRING
   9. CHAR-CODE <-> SYMBOL
  10. CHAR-INT <-> SYMBOL
  11. CHAR-CODE <-> ACCESSIBLE-SYMBOL
  12. CHAR-INT <-> ACCESSIBLE-SYMBOL
I oppose all coercions between characters and numbers as fundamentally
wrong-headed.  The existing coercion from integer to character should be
removed.
   4. STRING <-> SYMBOL
1-character symbols can already be coerced to characters, so allowing
coercion of symbols to strings would be okay, especially since the
function STRING already does it.  The inverse direction is a 2-argument
function and so should not be added; although Kent's suggestion of
returning an uninterned symbol is interesting, I suspect this is not
what users would expect.
   5. STRING <-> ACCESSIBLE-SYMBOL
2-argument function, also has subtype problem noted earlier.
   6. INTEGER <-> INTEGER-STRING
Multi-argument function in both directions unless you are base-ten-centric.
I don't think this is a good idea.
  13. PATHNAME <-> STRING
This is okay.  The function STRING already does pathname -> string in SCL.
  14. INTEGRAL-FLOAT <-> INTEGER
Integer -> float already exists.  The inverse would be okay except that
the INTEGRAL-FLOAT type is implementation-dependent, since whether a
mathematical value is a member of this type depends on the precision of
the floating-point representation of the machine; the explanation given
in CLtL that float -> integer conversion requires the user to think
about rounding applies, in my opinion.

I'd be in favor of removing COERCE from the language entirely.  Let's
look at what COERCE does that can't be easily done another way:

sequence to sequence coercion: same as CONCATENATE except that it
first does a TYPEP check and if satisfied, returns the argument
without copying it.

strings, symbols, and integers to character: there are already
functions to do this.

non-complex numbers to float: there are already functions to do this.

numbers to complex: combination of calling COMPLEXP and COMPLEX.

anything to t: same as IDENTITY.

I really don't think we would lose anything, aside from compatibility
with existing programs, by flushing COERCE.