[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Issue: PATHNAME-SYMBOL (Version 3)
- To: CL-Cleanup@SAIL.STANFORD.EDU
- Subject: Re: Issue: PATHNAME-SYMBOL (Version 3)
- From: David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>
- Date: Thu, 12 Nov 87 19:43 EST
- In-reply-to: <871110-125413-5509@Xerox>
Date: 10 Nov 87 12:53 PST
I don't want to appear capricious, but I'm finding that
PATHNAME-SYMBOL:NO fails to have sufficient reason for introducing an
incompatible change. Certainly, the original design of coercing symbols
as well as strings into pathnames is questionable, but, as long as we
are retaining some coercion, why change the coercions that are allowed?
Three comments: CLtL is inconsistent, specifying symbol->pathname coercion
in some places but not in others. symbol->pathname coercion and
stream->pathname coercion cannot coexist, since CLtL pp.33-4 does not
require symbol and stream to be disjoint. Until we fix that, we can't
require both stream->pathname and symbol->pathname coercions in any
single function, and after we fix that, I don't see much advantage to
putting symbol->pathname coercion back in.
We could just drop the issue, of course; it's not like fixing this one
thing would make the pathname and stream portion of CLtL wonderfully
clear and unambiguous.
(I'd also prefer to see that COERCE do explicitly what other functions
allow implicitly, e.g., (coerce "abc" 'pathname) = (pathname "abc"), but
that is certainly is another cleanup issue.
I like this idea.