[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Issue PATHNAME-PRINT-READ, v1
- To: KMP@STONY-BROOK.SCRC.Symbolics.COM
- Subject: Issue PATHNAME-PRINT-READ, v1
- From: Jon L White <firstname.lastname@example.org>
- Date: Sat, 7 Jan 89 21:51:44 PST
- Cc: IIM@ECLA.USC.EDU, CL-Cleanup@SAIL.Stanford.EDU
- In-reply-to: Kent M Pitman's message of Wed, 4 Jan 89 18:47 EST <890104184739.3.KMP@BOBOLINK.SCRC.Symbolics.COM>
re: - 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. . . .
I don't think Touretzky was thinking along those lines when he made
the #H proposal. Perhaps you are remember pieces of the following
message, which was part of a lengthy discussion that took place on
the Common-Lisp mailing list last summer.
-- JonL --
Date: Fri, 24 Jun 88 16:56:00 PDT
From: Jon L White <email@example.com>
Cc: ELIOT@cs.umass.edu, Moon@stony-brook.scrc.symbolics.com,
In-Reply-To: Cris Perdue's message of Fri, 17 Jun 88 10:16:38 PDT <8806171716.AA01554@clam.sun.com>
re: > (I don't count #.(make-hash-table...) because it's so gross.)
. . .
I would like to add my agreement to David Moon's statement. With the
#. readmacro you don't have to learn extra syntax to understand the
printed representation, and it is nothing if not adequately general.
Let's just say that it is "nothing". The problem with #. is precisely that
it is not syntax; rather, it is an "out" where the designers of the language
failed to come up with a syntax. To see this more clearly, consider writing
a trivial C program to read in "simple" Lisp expressions into equivalent data
structures of the C world. Parsing is no real problem [maybe could even
be yacc'd away], INTERNing of symbols is just a table lookup, numbers is
numbers [hey, even C can do fixnums and floats!], defstructs can be structs,
strings are strings, and so on; cons cells etc. can be cut out of mallocated
space, and pointer-type variables make it easly to link things together.
But there is no reasonable equivalent for the #. requirements -- no matter
how trivial the data-type returned, it implies the existence of a Lisp
EVALuator just to parse-&-build the representation. That's a LOT to require
for merely constructing up some simple data structures.
Thus while #. could be viewed as an adequate escape mechanism, it certainly
couldn't be part of a general interchange language.
And yet the hard problems are not limited to the "interchange" cases.
Consider file-processors other than LOAD or COMPILE-FILE (such as the
cross-reference program described by Tom Gruber in the first issue of
Lisp Pointers). Such a processor will want to READ a file of Lisp code,
but not necessarily evaluate anything in it. How will it react to the
file [named, say "/u/loser/trojan-horse.lisp"]:
(defun gift-horse (x)
-- JonL --