Re: Issue: PATHNAME-SYMBOL (Version 3)

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

    Date: 10 Nov 87 12:53 PST
    From: Masinter.pa@Xerox.COM

    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.