[Gcl-devel] Re: Compile test

[Paul F. Dietz]

Camm Maguire wrote:
> Greetings!  Regarding the test COMPILE.5 et.al.:
>
> (LET ((CL-TEST::X (COPY-SEQ "abc")))
>         (FUNCALL (COMPILE NIL
>                           (LIST 'LAMBDA NIL
>                                 (LIST 'EQ CL-TEST::X CL-TEST::X)))))
>
> If this is to return true, then compile cannot be implemented as a
> function.  Is this right?  Otherwise, as a function, all arguments are
> evaluated first, so from the function beginning, the form is already 
> (LAMBDA () (EQ "abc" "abc")).  This seems pretty radical.

The point of this is that COMPILE must preserve the object identity
of subterms in the lambda expression.  That is, the two strings
"abc" are actually the same object, and COMPILE must preserve
that fact.  This doesn't mean COMPILE can't be a function.  We
can rewrite this as:

(let* ((x (copy-seq "abc"))
       (lambda-expr (list 'lambda nil (list 'eq x x))))
    (assert (equal lambda-expr
                   '(lambda () (eq "abc" "abc"))))
    (funcall (compile nil lambda-expr)))

The variable lambda-expr is evaluated and its value, the
lambda term with the shared subterm, is passed to COMPILE.

The relevant section in the spec this paragraph from the
COMPILE page:

   Literal objects appearing in code processed by the compile
   function are neither copied nor coalesced. The code resulting
   from the execution of compile references objects that are eql
   to the corresponding objects in the source code.

Strings are EQL only when they are EQ, so the compiled version
of that lambda expression must have both "abc" strings be the
same object, and the EQ must therefore return true.

In contrast, this code must return NIL, because X and Y
are not EQ:

(let* ((x (copy-seq "abc"))
       (y (copy-seq x))
       (lambda-expr (list 'lambda nil (list 'eq x y))))
   (funcall (compile nil lambda-expr)))

        Paul