Slime 2.30: Discrepancy in eval versus pretty-eval of a `loop' expression
Slime Developers, The following was produced using SBCL version 2.3.11, slime-version "2.30", and Emacs version 29.4. (My copy of slime was installed using the ‘list-packages’ command in Emacs.) For the following ‘loop’ expression, the function ‘slime-eval-last-expression’ returns the correct result: (loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A (GENSYM)) (B (GENSYM)) (C (GENSYM))) But the function ‘slime-pprint-eval-last-expression’ does not return the correct result. Instead, it returns: (loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A . #1=((GENSYM))) (B . #1#) (C . #1#)) in the *slime-description* buffer. Is this a known error, that is, is it an acceptable result? Please let me know if there is any other information you need to reproduce or diagnose this potential error. Thank you. --
Hi check the *PRINT-CIRCLE* in both cases. I bet it is set differently. MA On Fri, Jul 26, 2024 at 8:41 PM Mark Harig <idirectscm@aim.com> wrote:
Slime Developers,
The following was produced using SBCL version 2.3.11, slime-version "2.30", and Emacs version 29.4. (My copy of slime was installed using the ‘list-packages’ command in Emacs.)
For the following ‘loop’ expression, the function ‘slime-eval-last-expression’ returns the correct result:
(loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A (GENSYM)) (B (GENSYM)) (C (GENSYM)))
But the function ‘slime-pprint-eval-last-expression’ does not return the correct result. Instead, it returns:
(loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A . #1=((GENSYM))) (B . #1#) (C . #1#))
in the *slime-description* buffer. Is this a known error, that is, is it an acceptable result?
Please let me know if there is any other information you need to reproduce or diagnose this potential error.
Thank you.
--
-- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
Thank you for your reply. I had not thought to check for any environment differences because both evaluations were done using Slime from a single Emacs buffer using C-x C-e (bound to `slime-eval-last-expression') and C-c C-p (bound to `slime-pprint-eval-last-expression'). Evaluation of *PRINT-CIRCLE* from the same buffer yields NIL. The following expression has the same problem: (let ((*print-circle* nil)) (loop :for n :in '(a b c) :collect `(,n (gensym)))) C-x C-e yields: => ((A (GENSYM)) (B (GENSYM)) (C (GENSYM))) C-c C-p yields: => ((A . #1=((GENSYM))) (B . #1#) (C . #1#)) in a *slime-description* buffer. Are you unable to reproduce these results? Is there some other factor to consider or check for? On Saturday, July 27, 2024 at 02:58:22 AM EDT, Marco Antoniotti <marco.antoniotti@unimib.it> wrote: Hi check the *PRINT-CIRCLE* in both cases. I bet it is set differently. MA On Fri, Jul 26, 2024 at 8:41 PM Mark Harig <idirectscm@aim.com> wrote: Slime Developers, The following was produced using SBCL version 2.3.11, slime-version "2.30", and Emacs version 29.4. (My copy of slime was installed using the ‘list-packages’ command in Emacs.) For the following ‘loop’ expression, the function ‘slime-eval-last-expression’ returns the correct result: (loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A (GENSYM)) (B (GENSYM)) (C (GENSYM))) But the function ‘slime-pprint-eval-last-expression’ does not return the correct result. Instead, it returns: (loop :for n :in '(a b c) :collect `(,n (gensym))) => ((A . #1=((GENSYM))) (B . #1#) (C . #1#)) in the *slime-description* buffer. Is this a known error, that is, is it an acceptable result? Please let me know if there is any other information you need to reproduce or diagnose this potential error. Thank you. -- -- Marco Antoniotti, Professor tel. +39 - 02 64 48 79 01 DISCo, University of Milan-Bicocca U14 2043 http://dcb.disco.unimib.it Viale Sarca 336 I-20126 Milan (MI) ITALY
I had not thought to check for any environment differences because both evaluations were done using Slime from a single Emacs buffer using C-x C-e (bound to `slime-eval-last-expression') and C-c C-p (bound to `slime-pprint-eval-last-expression'). Evaluation of *PRINT-CIRCLE* from the same buffer yields NIL. The following expression has the same problem:
it's not environmental differences, but a peculiarity of slime's implementation. one of them calls SWANK:INTERACTIVE-EVAL on the CL side, and the other calls SWANK:PPRINT-EVAL. the latter configures the printer differently (i.e. enables *PRINT-CIRCLE*). but notice that the two outputs are the same semantically. one of them just also annotates the cons cell identities. in short: it's a peculiarity of the current slime implementation, but i wouldn't call it a bug. -- • attila lendvai • PGP: 963F 5D5F 45C7 DFCD 0A39 -- “Heed these words, you who wish to probe the depths of nature: if you do not find within yourself that which you seek, neither will you find it outside. If you ignore the wonders of your own house, how do you expect to find other wonders? In you is hidden the treasure of treasures. Know Thyself and you will know the Universe and the Gods.” — Oracle of Delphi, (c. 8th century BC)
On Monday, July 29, 2024 at 06:35:45 AM EDT, Attila Lendvai <attila@lendvai.name> wrote:
it's not environmental differences, but a peculiarity of slime's implementation. one of them calls SWANK:INTERACTIVE-EVAL on the CL side, and the other calls SWANK:PPRINT-EVAL.
the latter configures the printer differently (i.e. enables *PRINT-CIRCLE*). but notice that the two outputs are the same semantically. one of them just also annotates the cons cell identities.
in short: it's a peculiarity of the current slime implementation, but i wouldn't call it a bug.
OK. I see that the result is (semantically) the same. The following at the REPL causes `slime-eval-last-expression' to return the same value as `slime-pprint-eval-last-expression': CL-USER> *print-circle* NIL CL-USER> (setf *print-circle* t) T CL-USER> (loop :for n :in '(a b c) :collect `(,n (gensym))) ((A . #1=((GENSYM))) (B . #1#) (C . #1#)) The documentation for both `slime-eval-last-expression' and `slime-pprint-eval-last-expression' does not mention this difference in either docstrings, and neither function is documented in the Slime (info) manual (although their key bindings are). It would be helpful for users to have it documented that the pprint function (indirectly) changes the value of *PRINT-CIRCLE* and that, therefore, the user should expect the pretty-print printed representation to differ sometimes from the standard evaluation. Thank you for your response and clarification about what is going on in this Slime behavior. --
participants (3)
-
Attila Lendvai -
Marco Antoniotti -
Mark Harig