Issue PATHNAME-PRINT-READ, v1

[Jon L White <jonl@lucid.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 <edsel!jonl@labrea.stanford.edu>
  To: cperdue@sun.com
  Cc: ELIOT@cs.umass.edu, Moon@stony-brook.scrc.symbolics.com,
	  common-lisp@sail.stanford.edu
  In-Reply-To: Cris Perdue's message of Fri, 17 Jun 88 10:16:38 PDT <8806171716.AA01554@clam.sun.com>
  Subject:  #.

  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 --