Re: Issue: COERCE-INCOMPLETE (Version 2)

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

    Date: 9 Dec 88 16:47 PST
    From: masinter.pa@Xerox.COM

    So why don't we just define:
    (coerce x 'string) == (string x)

This is the whole problem.  Leaving aside the cases that are
currently required to signal an error, (string nil) => "nil"
and (coerce nil 'string) => "" are currently required by CLtL.
So one way or another this would be an incompatible change.
Maybe it would be worth the incompatible change for the
increased consistency, who knows?  I don't like incompatible
changes.

    (coerce x 'character) == (character x)

Already true by definition (CLtL p.241).

    (coerce x 'pathname) = (pathname x)

Good idea.

    (coerce x 'float) = (float x),

Already true; not by definition, but deducible from CLtL.

Also (coerce x 'rational) = (rational x) would be a good idea,
don't you think?  CLtL p.52 indicates this was left out because
the user should have to decide explicitly whether to use rational
or rationalize.

The other functions that are also names of types that can be used
as type-specifiers without arguments are:

ATOM 
BIT 
BREAK -- condition system type
COMPLEX 
CONS 
ERROR -- condition system type
FUNCTION 
LIST 
NULL 
VECTOR 

except for FUNCTION, none of these is a coercer.  Should
(coerce x 'function) = (eval `(function ,x))?  Actually that
may have already been added to the language by the function-type
proposal, I forget.

    I might think that
    (coerce nil 'string) might well return a different value than
    (coerce nil '(vector character)).

I think that would be a really bad idea!  It's hard to be sure, but
I think CLtL's definition of COERCE very carefully skates around
any problems like this.  Making (coerce x 'string) = (string x)
might introduce this problem if we're not careful.

I think I've just been led back to the same place I always end up
when thinking about COERCE, even though that's not what I expected
at all when I started this message.  We should either leave COERCE
essentially the way it is or get rid of it.  I appreciate Larry's
argument that it's good to have because you know a lot about what
it will do even without knowing the specific coercions for the
target type.