[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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 --