[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue: COERCE-FROM-TYPE (Version 1)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Issue: COERCE-FROM-TYPE (Version 1)
- From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Mon, 20 Jun 88 12:19 EDT
References: COERCE (p51)
Edit history: 20-Jun-88, Version 1 by Pitman
Status: For Internal Discussion
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.
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.
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
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.
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.
A part of the language which is currently in somewhat of a disarray
would become more organized, making it simpler to explain and easier
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.