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.

--

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.

--