PATHNAME-SYMBOL

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

    Date: Mon, 1 Jun 87 14:27:11 PDT
    From: edsel!kent-state!eb@navajo.stanford.edu (Eric Benson)

    If a symbol can be coerced into a string, and a string can be coerced
    into a pathname, I see no reason why a symbol should not be coerced
    into a pathname.  It has limited usefulness, but I believe that
    coercions should be transitive.  I believe that the aesthetics of the
    language will be harmed by disallowing symbols as pathnames.

    I'm not going to put up a fight to stop this change, but I would like
    to see the minority view stated in the proposal.

Stating minority views in proposals is a good idea, but don't forget the
following point KMP made a couple of weeks ago.  I only mention this
because the point about alphabetic case doesn't appear explicitly in the
version 2 writeup.  I'd say the succinct form of this point is that
strings preserve the case that you type in, but symbols don't, they
force to uppercase.  This doesn't affect me, since I don't enjoy a file
system with case-sensitive file names, but it affects a lot of people.

 * Note that the biggest impact of this change on users is that
   they will not be able to say (LOAD'FOO) which they commonly type
   interactively to mean (LOAD "FOO"). One advantage, of course, is
   that in case-sensitive file systems, people won't do
   (load'foo) and wonder why file "FOO" (rather than "foo") is not
   found. Still, I think the fact that we're going to make it an
   error for people to type (LOAD 'FOO) is worth documenting as part
   of the cost of this proposal so that no one ends up surprised.

One note I had about KMP's remark:
Nothing in CLtL says that a symbol is allowed as an argument to LOAD,
unless we take all occurrences of the string "filename" in italics
to be typos for "pathname" in italics.  See pp.413,418,426.