3 ms·

> If that were true I would consider it a very weird Common Lisp implementation. One of those is called SBCL. 'The main point' is that you can't depend on the

by lispm 5y ago

> If that were true I would consider it a very weird Common Lisp implementation. One of those is called SBCL. 'The main point' is that you can't depend on the value of (EQ '(a b) '(a b)) being NIL. Reason: a compiler compiles a Lisp file. The compiler sees literal data like '(a b) ' and '(a b). The compiler determines that these are 'similar' objects and 'coalesces' them into one object. It might even do it for '(a b) and '(1 a b), seeing that one is a sublist of the other and coalesces the first list into the sublist of the other. Common Lisp compilers are explicitly allowed by the language standard to do these things with literal data in a source file. It defines a concept of 'similarity', where this is allowed.

dreamcompiler 5y ago
$ sbcl This is SBCL 1.5.8.138-d53fb0eb3, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. * (eq '(a b) '(a b)) NIL * Which is exactly what I'd expect in any normal (non-weird) Common Lisp implementation. Is your SBCL returning T for this?
- lispm 5y ago
  put it into a file, compile it, load it, run it: /tmp % more test.lisp (print (list :eq-or-not (eq '(a b) '(a b)))) /tmp % sbcl This is SBCL 2.1.9, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load (compile-file "test.lisp")) ; compiling file "/private/tmp/test.lisp" (written 03 JAN 2022 07:58:54 PM): ; processing (PRINT (LIST :EQ-OR-NOT ...)) ; wrote /private/tmp/test.fasl ; compilation finished in 0:00:00.003 (:EQ-OR-NOT T) T
  - dreamcompiler 5y ago
    Excellent example of a place where the file compiler can differ from the REPL, and as you point out this is perfectly legal. It's why #'eq is often not the best equality predicate unless you know what you're doing. CCL and Lispworks return NIL for this test in both cases.
- deleted 5y ago
  [deleted]

by lispm 5y ago

dreamcompiler 5y ago

$ sbcl This is SBCL 1.5.8.138-d53fb0eb3, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. * (eq '(a b) '(a b)) NIL * Which is exactly what I'd expect in any normal (non-weird) Common Lisp implementation. Is your SBCL returning T for this?

lispm 5y ago
put it into a file, compile it, load it, run it: /tmp % more test.lisp (print (list :eq-or-not (eq '(a b) '(a b)))) /tmp % sbcl This is SBCL 2.1.9, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (load (compile-file "test.lisp")) ; compiling file "/private/tmp/test.lisp" (written 03 JAN 2022 07:58:54 PM): ; processing (PRINT (LIST :EQ-OR-NOT ...)) ; wrote /private/tmp/test.fasl ; compilation finished in 0:00:00.003 (:EQ-OR-NOT T) T
- dreamcompiler 5y ago
  Excellent example of a place where the file compiler can differ from the REPL, and as you point out this is perfectly legal. It's why #'eq is often not the best equality predicate unless you know what you're doing. CCL and Lispworks return NIL for this test in both cases.
deleted 5y ago
[deleted]