[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue PATHNAME-PRINT-READ, v1, and then some
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM, IIM@ECLA.USC.EDU
- Subject: Issue PATHNAME-PRINT-READ, v1, and then some
- From: Glenn S. Burke <gsb@ALDERAAN.SCRC.Symbolics.COM>
- Date: Thu, 5 Jan 89 23:26 EST
- Cc: CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: <890104184739.3.KMP@BOBOLINK.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
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.