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.
--
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.
- 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))
- 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.
- *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.
--
On Thursday, January 30, 2025 at 01:25:12 PM EST, Stas Boukarev stassats@gmail.com wrote:
Yes. #2A is not read correctly. But then, do you really need to be evaluating constants in buffers?
It depends on the source of the error in the Slime code. If these array literals are not evaluated, could it be an indicator of a problem that would show up in other contexts? If so, then developers might spend time attempting to track down an error in their code that does not exist -- the error might be an evaluation problem in Slime. It is useful to have this problem identified because it localizes the problem to a small area (which could then be repaired), rather than having it as a symptom in a larger expression.
If this evaluation problem turns out NOT to be resolvable, then it could be added to a list of Known Problems section in the Slime info manual so that others can look it up and not report it again.
--
-
Mark Harig -
Stas Boukarev