emacs 28.1 unable to launch slime (cl is deprecated)

Question

I installed emacs via brew: brew install emacs and got version 28.1 (my OS version is macOS 11.6.1). I immediately ran package-install + slime.

When I run slime command I get:

Package cl is deprecated

When I run the command for 2nd time I get:

Wrong number of arguments (3 . 4), 2

I am complete newbie to emacs and lisp, I'm just trying to set up the environment so I can complete tutorial.

When running with toggle-debug-on-error option I get the following output:

Debugger entered--Lisp error: (wrong-number-of-arguments (3 . 4) 2)
  #f(compiled-function (obsolete-name current-name when &optional docstring) "Make OBSOLETE-NAME a variable alias f$
  (define-obsolete-variable-alias 'common-lisp-glossary-fun 'common-lisp-hyperspec-glossary-function)
  eval-buffer(#<buffer  *load*-964107> nil "/Users/user/.emacs.d/elpa/slime-2.26.1/li..." nil t)  ; Readin$
  load-with-code-conversion("/Users/user/.emacs.d/elpa/slime-2.26.1/li..." "/Users/user/.emacs.d/$
  require(hyperspec "lib/hyperspec")
  eval-buffer(#<buffer  *load*> nil "/Users/user/.emacs.d/elpa/slime-2.26.1/sl..." nil t)  ; Reading at bu$
  load-with-code-conversion("/Users/user/.emacs.d/elpa/slime-2.26.1/sl..." "/Users/user/.emacs.d/$
  autoload-do-load((autoload "slime" "Start a Lisp subprocess and connect to its Swank s..." t nil) slime)
  command-execute(slime record)
  execute-extended-command(nil "slime" "slime")
  funcall-interactively(execute-extended-command nil "slime" "slime")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)

Answer 1

It looks like define-obsolete-variable-alias is defined as an Emacs Lisp macro.

I would like to guess that there might be something in how the macro expansion for define-obsolete-variable-alias is being compiled, such that may be resulting in the error.

If it may be possible to develop a short sort of workaround for the error, the following should serve to ensure that hyperspec.el is newly recompiled by Emacs. This uses a syntax like for keys/commands entered in the Emacs minibufer

1. M-X find-library RET slime RET
2. M-X find-file RET lib/hyperspec.el RET
3. M-X byte-compile-file RET RET

Concerning the two 'RET' i.e 'return' keys entered with the third item: When not specifying any file in the interactive call to byte-compile-file, or when entering an empty string when it asks for a file in the minibuffer, then it should use the file in the selected buffer - e.g hyperspec.el under that source location.

This basically recompiles the "lib/hyperspec.el" located under the same load-path directory as "slime.el". This recompiled hyperspec.elc would then be loaded when the following is evaluated newly, in slime.el

(require 'hyperspec "lib/hyperspec")

One of slime.elc (byte-compiled file) or slime.el (the source file for slime.elc) would have been loaded as due to an autoload form created when the slime package was installed, such that the slime interactive command would load slime (dot-elc or dot-el) to define the actual slime command. Emacs then tries to load every library that has a require form in slime.el, when evaluating the bytecode (or source code) for slime.el, thus to the point where the macroexpansion (??) fails.

After recompiling hyperspec.el, hopefully it might serve to clear up any possible issue with the compiled macroexpansion form, at this instance.

I don't believe it should be necessary to restart Emacs, at that point. Entering the interactive slime command in the minibuffer again then, does the issue clear up somehow?

If that does not work out, then if simply loading that hyperspec.el as a source file -- as instead of its (ordinarily preferred) hyperspec.elc -- this might serve to work around the issue, albeit, skipping any optimizations in any byte-compiled form of the file. Removing hyperspec.elc would be one way to approach this, as to ensure that hyperspec.el is loaded instead.