Issue PATHNAME-PRINT-READ, v1, and then some

[Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>]

    Date: Wed, 4 Jan 89 18:47 EST
    From: Kent M Pitman <KMP@STONY-BROOK.SCRC.Symbolics.COM>

    Yes, hosting is an issue that I deliberately glossed in the proposal.
    Let me say a few words about that and other issues that have been raised.

     - I think #P is better than #. for the same reasons that Touretzky
       proposed #H instead of relying on #. . That is, because most Lisp
       data can be understood by engines considerably less complex than
       Lisp itself. Lists, numbers, etc. are parseable and manipulable
       [are those really words? I say them a lot but they look funny 
       written down..] by simpler programs which do not contain EVAL.
       Using #. makes a large barrier to such programs in manipulating
       any data involving pathnames, which a priori should not be an
       opaque concept to non-Lisp programs.

    . . .

I would strongly prefer that a more generic approach be taken to
allocating reader syntax.

Previously #S has been suggested as the obvious place for extensions
such as this to occur.  In retrospect, I think that a slightly different
syntax should be reserved for extension by Common Lisp, in order that
any existing #S usage by particular implementations not conflict with
extensions dictated by CL.

e.g., if #T(typename ...) is reserved as the area of extension, then if
CL says that pathnames are read as #T(PATHNAME "namestring") there would
be no conflict for an implementation which happened to implement the
readableness of pathnames through the #S syntax already.  Such an
implementation should print a pathname using #T(PATHNAME "namestring")
and read both its older #S(PATHNAME :name whatever ...) and the #T
syntax.

No implementation would be permitted to extend this syntax, therefore
there would never be any conflict when it is extended by CL.

Doing this does not preclude eventual expansion of a user's ability to
define #S syntax (something I think should be done).  It DOES give CL a
place to expand read syntax into without using up all of the dispatch
characters, something which is beginning to look pretty likely.