Yes. #2A is not read correctly. But then, do you really need to be evaluating constants in buffers? On Thu, Jan 30, 2025 at 9:21 PM Mark Harig <idirectscm@aim.com> wrote:

Slime Developers,

There appears to be a problem with Slime’s evaluation of multi-dimensional array literals in some buffers. Evaluation of 1-dimensional array literals does not trigger this problem.

1. At the Slime REPL, no error:

CL-USER> #(1 2 3) #(1 2 3) CL-USER> #2A((1 2 3) (4 5 6)) #2A((1 2 3) (4 5 6))

2. Using the Slime command ‘slime-interactive-eval’, no error:

M-x slime-interactive-eval Slime Eval: #(1 2 3) => #(1 2 3)

M-x slime-interactive-eval Slime Eval: #2A((1 2 3) (4 5 6)) => #2A((1 2 3) (4 5 6))

However, if these array literals are evaluated in the *slime-scratch* buffer using C-x C-e (bound to ‘slime-eval-last-expression’), then the 1-D array literal is evaluated as expected, while the 2-D array literal triggers an error.

3. *slime-scratch* buffer (or any Lisp buffer associated with a Lisp source file):

#(x y z) => #(x y z)

#2A((1 2) (3 4)) => Execution of a form compiled with errors. Form: ((1 2) (3 4)) Compile-time error: illegal function call [Condition of type SB-INT:COMPILED-PROGRAM-ERROR]

Note that if the multi-dimensional array literal is marked in an Emacs buffer and the command ‘slime-eval-region’ is invoked, then the evaluation does not not trigger the error, above.

This problem is occurring with slime 2.30, Emacs 29.4, and SBCL 2.3.11.

--