[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: COERCE-INCOMPLETE (Version 2)
- To: cl-cleanup@sail.stanford.edu
- Subject: Re: Issue: COERCE-INCOMPLETE (Version 2)
- From: masinter.pa@Xerox.COM
- Date: 9 Dec 88 16:47 PST
This issue is Not Ready for mailing. We need to pick a set of possibilities
if we can't agree. Perhaps we can have this ready for discussion next
month.
I see we have some choices:
a) remove COERCE
b) leave COERCE alone
c) extend COERCE slightly
d) extend COERCE a lot
I think (b) or (c) are the best. I'll try to say why:
We've observed that it is sometimes difficult to tell when you should use
COERCE -- that there are some conversions that COERCE does not do that some
users might "expect" it to do.
However, COERCE does have the nice property that you can tell what it is
doing. That is, programs that use COERCE, whether (COERCE x 'STRING) or
(COERCE x 'FLOAT), it is easy to see that the results of these will be a
string or float repsectively, that if the input is of the desired type it
will be left alone, and otherwise it will be converted. So I think that
Common Lisp with COERCE is a better language than Common Lisp without it.
Certainly it is possible to write programs without COERCE, but they won't
be as easy to read.
COERCE embodies two operations: a type check plus a conversion if the type
check is not satisfied. I think (COERCE x y) is valid for all type
specifiers y, even those which have no conversions, and that (COERCE x 'y)
in those cases is a form of (TYPE-CHECK x y).
I think that many of the extensions proposed in Version 2 are far-fetched.
The more we burden COERCE with multiple kinds of arguments the worse we
make it.
One of the problems with COERCE is that the second argument is treated both
as a type specifier and also an indicator for the type of conversion
wanted. I might think that
(coerce nil 'string) might well return a different value than
(coerce nil '(vector character)).
The major problems come where (coerce x 'type) operates differently than
the 'natural' coerce function for type, viz: string, character, pathname,
float.
So why don't we just define:
(coerce x 'string) == (string x)
(coerce x 'character) == (character x)
(coerce x 'pathname) = (pathname x)
(coerce x 'float) = (float x),