What is a compiler (vol. 63827) meets what are gensyms.

[David C. Plummer <DCP@SCRC-QUABBIN.ARPA>]

    Date: Thu, 17 Apr 86 14:15 PST
    From: Gregor.pa@Xerox.COM


    In this issue the subject of what compile file is required to do with
    top-level forms meets the subject of top-level calls to macros which
    expand into code containing gensyms.

    Suppose I have the following macro.

    (defmacro foo (x y)
      (let ((var (gensym))
	    (nv-var (gensym)))
	`(progn
	   (defun ,x ..)
	   (defun ,y ..)
	   (defsetf ,x (,var) (,nv-var) `(,',y ,,var ,,nv-var)))))

    And I have a file that includes the form:

     (FOO BAR SET-BAR)

    [ For clarities sake, the point is that the macro expands
      to a progn that includes a defsetf that has gensyms for
      the access-function-args and storing-variables, like this:

      (DEFSETF BAR (#:G1890) (#:G1891) `(SET-BAR ,#:G1890 ,#:G1891))
    ]

    Is compiling and loading the file legal Common Lisp?

    Is the original foo macro legal Common Lisp?

    I claim that the answer to both questions is yes.  After all, it is
    clearly legal interpreted/compiled to core Common Lisp.

    I believe that CLtL is "silent" on this issue.

    I got bit by a Common Lisp compiler which macroexpands top-level forms,
    but which does not necessarily compile the entire result of the
    macroexpansion.  In this particular case the compiler expanded the two
    defuns, but left the defsetf as (store-setf '<list with gensyms in it>)
    Then the dumper dumped that list in such a way that when the file was
    loaded the gensyms which should have been eq were not.

My opinion is that what you are doing is legal.  My guess is that the
dumper/loader you are using dumps all symbols as (more-or-less)
package::print-name.  This WILL preserve EQness for non-gensyms but
loses for gensyms.

I think CLtL must be very explicit about what is preserved in the
load/dump process.  The Symbolics implementation is EQUAL for lists and
EQL for everything else.