Re: Issue: PATHNAME-SYMBOL (Version 3)

[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?

This issue contrasts in an interesting way with FUNCTION-TYPE, where I
prefer removing all coercions; in this case, since some coercions are
being left (in particular, coercing from a string to a pathname),
shouldn't all "reasonable" coercions be allowed? 

One definition for a "reasonable" coercion is one where there is a
simple way to convert from one type to another and alternative
conversions are considerably more complex. I think this holds for
symbol->pathname, symbol->string, string->pathname. The reason why
coercions need not be transitive is that following a->b->c is more
complex than either a->b or b->c. 

(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.

Version 3 of the proposal did not include an endorsement summary. So
far, Steele, Pitman, Moon explicitly endorsed PATHNAME-SYMBOL:NO, Eric
Benson argued against it.