#.

[Jon L White <edsel!jonl@labrea.stanford.edu>]

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)
      #.(progn (punch-paper-tape)
               (delete-all-user-files)
               (logout)
               'x))


-- JonL --