Re: Issue: COERCE-INCOMPLETE (Version 2)

[David N Gray <Gray@DSG.csc.ti.com>]

> Problem Description:
> 
>   COERCE is difficult to extend because ambiguities arise about the
>   source type of the coercion.
> 
>   For example, if the symbol STRING were permitted as a second argument
>   to coerce, as in (COERCE NIL 'STRING), there would be two posssible
>   return values: "" or "NIL". The choice would be arbitrary and would
>   have to be specified by the documentation. No matter which was chosen,
>   it would probably turn out to be a problem for some applications at
>   some times.

In my opinion, I don't buy this as being a valid problem.  There are
actually more possibilities than you have listed -- converting NIL to a
string might be desired to result in "", "()", "NIL", "nil", "Nil", or
"LISP:NIL" depending on what the user has in mind.  Granted that 
(COERCE NIL 'STRING 'SYMBOL) may be easier to remember than using 
SYMBOL-NAME or using (FORMAT NIL ...) and having to decide whether to
use ~A or ~S, what *PRINT-CASE* should be, etc., but is that really
making it easier for the user to get the result he wants, or is it just
allowing him to write code without having to think about what he really
means?   

>   14. INTEGRAL-FLOAT <-> INTEGER
> 
>       a. (COERCE x 'INTEGER 'INTEGRAL-FLOAT)
> 	 == (TRUNCATE x)
> 
>       b. (COERCE x 'INTEGRAL-FLOAT 'INTEGER)
> 	 == (FLOAT x)

There are several specific cases I could pick on, but here, for example,
if a user can't remember the TRUNCATE function, how is he going to
remember the INTEGRAL-FLOAT type and understand how to use it correctly?
TRUNCATE seems a much simpler concept.