Issue: COERCE-FROM-TYPE (Version 1)

[Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:          COERCE-FROM-TYPE
References:     COERCE (p51)
Related-Issues: COERCE-INCOMPLETE
Category:       ADDITION
Edit history:   20-Jun-88, Version 1 by Pitman
Status:	        For Internal Discussion

Problem Description:

  COERCE is difficult to extend because ambiguities arise about the
  source type of the coercion.

  For example, should (COERCE NIL 'STRING) return "" or "NIL".
  The choice would be arbitrary unless you knew whether NIL was being
  viewed as an empty list or a symbol.

  Similarly, (COERCE (CHAR-CODE #\A) 'STRING) might return the same
  as (FORMAT NIL "~D" (CHAR-CODE #\A)) -- "65" in most ASCII-based
  implementations -- or it might return "A", depending on whether the
  result of char-code was viewed as a number or more specifically as
  a character code.

Proposal (COERCE-FROM-TYPE:NEW-ARGUMENT):

  Add an extra optional argument to COERCE which specifies the type
  from which the coercion is to be done. The new syntax would be:

   COERCE object to &optional (from (TYPE-OF object))

  Constrain that FROM must be such that (TYPEP OBJECT FROM) is true.

Rationale:

  This leaves room for a subsequent proposal to extend COERCE in
  interesting ways. For example, extensions such as the following
  might be considered:

   (COERCE NIL 'STRING 'LIST)   => ""
   (COERCE NIL 'STRING 'SYMBOL) => "NIL"

  A new type CHAR-CODE might even be introduced as
   (DEFTYPE CHAR-CODE () `(INTEGER 0 (,CHAR-BITS-LIMIT)))
  so that COERCE could handle cases like:

   (EQUAL (COERCE (CHAR-CODE #\A) 'STRING 'NUMBER)
	  (FORMAT NIL "~D" (CHAR-CODE #\A))) => T
   (COERCE (CHAR-CODE #\A) 'STRING 'CHAR-CODE) => "A"

  Such specific proposals are deliberately not part of this proposal
  in order to separate the general purpose mechanism from the more
  specific details.

Current Practice:

  Probably no one implements the proposed behavior at this time.

Cost to Implementors:

  The more optimization a compiler does (or might do) of COERCE, the more
  work might be necessary. In general, however, the changes would probably
  not involve a major amount of work.

Cost to Users:

  This change is upward compatible.

Cost of Non-Adoption:

  Various proposals to extend COERCE would probably not pass because
  not everyone can agree on how to view the type of the first argument
  when more than one type is possible.

Benefits:

  More (if not all) kinds of coercions in the language would be able
  to go through COERCE. Documentation and ease of use would be simplified.

Aesthetics:

  A part of the language which is currently in somewhat of a disarray
  would become more organized, making it simpler to explain and easier
  to learn.

Discussion:

  Pitman wrote and supports COERCE-FROM-TYPE:NEW-ARGUMENT.

  Pitman is also studying similar generalizations of EQUAL and COPY that
  might address the numerous problems with those operators.

  The main obstacle to extending COERCE in the past has been that when an
  object could be viewed as more than one type, confusion might result if
  people did not agree on the view in use. Since if this proposal passed
  there is a way to specify the view type of the object going in, it might
  then be worth considering whether COERCE should be made generic and
  whether a standard protocol for extending it could be defined.