[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: COERCE-INCOMPLETE (Version 2)
- To: email@example.com
- Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Fri, 30 Dec 88 18:24 EST
- In-reply-to: <881209-164733-1437@Xerox>
Date: 9 Dec 88 16:47 PST
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
(coerce x 'character) == (character x)
Already true by definition (CLtL p.241).
(coerce x 'pathname) = (pathname x)
(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
The other functions that are also names of types that can be used
as type-specifiers without arguments are:
BREAK -- condition system type
ERROR -- condition system type
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