abcl icon indicating copy to clipboard operation
abcl copied to clipboard

EQness lost

Open melisgl opened this issue 4 years ago • 3 comments

Consider the following repl transcript:

CL-USER(1): (lisp-implementation-version)
"1.8.0"
"OpenJDK_64-Bit_Server_VM-Debian-11.0.13+8-post-Debian-1deb11u1"
"amd64-Linux-5.10.46-5rodete1-amd64"
CL-USER(2): (defmacro fff (form)
 `(eq ',form ',form))
FFF
CL-USER(3): (funcall (compile nil (lambda () (defun ggg () (fff (1+ 2))))))
GGG
CL-USER(4): (ggg)
NIL

GGG returns NIL, but that should be impossible as it should boil down to (EQ '#1=(1+2) '#1#).

I don't know the spec well enough to judge whether this is legal behaviour. For what it's worth, on AllegroCL, CLISP, CMUCL, ECL and SBCL GGG returns T.

melisgl avatar Dec 01 '21 08:12 melisgl

You need to use eql for it to be sure to work for numbers. https://stackoverflow.com/questions/547436/whats-the-difference-between-eq-eql-equal-and-equalp-in-common-lisp

Alan

On Wed, Dec 1, 2021 at 3:29 AM Gábor Melis @.***> wrote:

Consider the following repl transcript:

CL-USER(1): (lisp-implementation-version) "1.8.0" "OpenJDK_64-Bit_Server_VM-Debian-11.0.13+8-post-Debian-1deb11u1" "amd64-Linux-5.10.46-5rodete1-amd64" CL-USER(2): (defmacro fff (form) `(eq ',form ',form)) FFF CL-USER(3): (funcall (compile nil (lambda () (defun ggg () (fff (1+ 2)))))) GGG CL-USER(4): (ggg) NIL

GGG returns NIL, but that should be impossible as it should boil down to (EQ '#1=(1+2) '#1#).

I don't know the spec well enough to judge whether this is legal behaviour. For what it's worth, on AllegroCL, CLISP, CMUCL, ECL and SBCL GGG returns T.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/armedbear/abcl/issues/416, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDTPLUFKGH2K226JZG3UOXMFTANCNFSM5JD23EEA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

alanruttenberg avatar Dec 01 '21 17:12 alanruttenberg

I'm aware of the differences between EQ*, but in this case a literal list is compared with, hopefully, itself.

melisgl avatar Dec 01 '21 17:12 melisgl

Ah, my bad. Yes, strange (wrong) behavior. Compiling ggg alone does as expected. The other way yields something like the following, which reads the form twice and so not eq. Bug. Gonna be fun to track that down.

public final class test_4 extends CompiledPrimitive {

        static final LispObject OBJ342900 =

Lisp.readObjectFromString("(1+ 2)"); static final LispObject OBJ342899 = Lisp.readObjectFromString("(1+ 2)");

        public final LispObject execute()
        {

/* 3*/ if (OBJ342899 == OBJ342900) { /* 3*/ return Lisp.T; } else { /* 3*/ return Lisp.NIL; } }

        public test_4()
        {
            super(Lisp.internInPackage("GGG", "COMMON-LISP-USER"),

Lisp.NIL); }

}

On Wed, Dec 1, 2021 at 12:28 PM Gábor Melis @.***> wrote:

I'm aware of the differences between EQ*, but in this case a literal list is compared with - hopefully -itself.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/armedbear/abcl/issues/416#issuecomment-983865655, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAB3CDWVVYNXYTCEL3JCXW3UOZLKHANCNFSM5JD23EEA . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

alanruttenberg avatar Dec 02 '21 06:12 alanruttenberg

IMHO it is not a bug

The macro

(defmacro fff (form)
  `(eq ',form ',form))

can be translated to:

(defmacro fff (form)
  (list 'eq (list 'quote form) (list 'quote form)))

which is creating two different lists sharing the same CADR, and then not EQ

For achieve the EQness required we should use this macro (or some other equivalent)

(defmacro fff (form)
  (list 'eq form form))

I'm attaching a short session to illustrate it

CL-USER> (lisp-implementation-version)
"1.9.2-dev"
"OpenJDK_64-Bit_Server_VM-Ubuntu-11.0.19+7-post-Ubuntu-0ubuntu122.04.1"
"amd64-Linux-5.19.0-45-generic"
CL-USER> (defmacro fff (form)
 `(eq ',form ',form))
FFF
CL-USER> (funcall (compile nil (lambda () (defun ggg () (fff (1+ 2))))))
GGG
CL-USER> (ggg)
NIL
CL-USER> (defmacro fff (form)
  (list 'eq (list 'quote form) (list 'quote form)))
FFF
CL-USER> (funcall (compile nil (lambda () (defun ggg () (fff (1+ 2))))))
GGG
CL-USER> (ggg)
NIL
CL-USER> (defmacro fff (form)
  (list 'eq form form))
FFF
CL-USER> (funcall (compile nil (lambda () (defun ggg () (fff (1+ 2))))))
GGG
CL-USER> (ggg)
T
CL-USER>

alejandrozf avatar Jun 30 '23 18:06 alejandrozf

You are right. The spec requires only EQUALness (http://www.lispworks.com/documentation/HyperSpec/Body/02_df.htm).

melisgl avatar Jul 03 '23 08:07 melisgl