Re: Slime 2.30: Discrepancy in eval versus pretty-eval of a `loop' expression

------=_Part_622726_1701477021.1722272191073
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

 On Monday, July 29, 2024 at 06:35:45 AM EDT, Attila Lendvai <[email protected]> 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.

--
  
------=_Part_622726_1701477021.1722272191073
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div>                On Monday, July 29, 2024 at 06:35:45 AM EDT, Attila Le=
ndvai &lt;[email protected]&gt; wrote:<br><br>&gt; it&#39;s not environme=
ntal differences, but a peculiarity of slime&#39;s implementation.<br>&gt; =
one of them calls SWANK:INTERACTIVE-EVAL on the CL side, <br>&gt; and the o=
ther calls SWANK:PPRINT-EVAL.<br><br>&gt; the latter configures the printer=
 differently (i.e. enables *PRINT-CIRCLE*). <br>&gt; but notice that the tw=
o outputs are the same semantically. <br>&gt; one of them just also annotat=
es the cons cell identities.<br><br>&gt; in short: it&#39;s a peculiarity o=
f the current slime implementation, but i wouldn&#39;t call it a bug.<br><b=
r>OK.  I see that the result is (semantically) the same.<br><br>The followi=
ng at the REPL causes `slime-eval-last-expression&#39; to return the same v=
alue<br>as `slime-pprint-eval-last-expression&#39;:<br><br>CL-USER&gt; *pri=
nt-circle*<br>NIL<br>CL-USER&gt; (setf *print-circle* t)<br>T<br>CL-USER&gt=
; (loop :for n :in &#39;(a b c) :collect `(,n (gensym)))<br>((A . #1=3D((GE=
NSYM))) (B . #1#) (C . #1#))<br><br>The documentation for both `slime-eval-=
last-expression&#39; and <br>`slime-pprint-eval-last-expression&#39; does n=
ot mention this difference in either<br>docstrings, and neither function is=
 documented in the Slime (info) manual<br>(although their key bindings are)=
. <br><br>It would be helpful for users to have it documented that the ppri=
nt function <br>(indirectly) changes the value of *PRINT-CIRCLE* and that, =
therefore, the <br>user should expect the pretty-print printed representati=
on to differ sometimes<br>from the standard evaluation.<br><br>Thank you fo=
r your response and clarification about what is going on in this<br>Slime b=
ehavior.<br><br>--<br>            </div>           =20
------=_Part_622726_1701477021.1722272191073--