error on defconstant

[doongjohn]

This runs fine when I run sbcl --load main.cl but Alive: Load file to REPL does not work because of this error.

[madkins23]

Thanks for reporting this interesting issue.

As a work-around you can get past the error by clicking on the first choice in the debug view to the right:

to Go ahead and change the value.

Note that you will have this issue if you load the same file multiple times in the same editing session. SBCL will also raise this error if you load the same file multiple times from the REPL:

This is SBCL 2.3.2, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
(load "issue-148.lisp")
t
(load "issue-148.lisp")
While evaluating the form starting at line 2, column 0
  of #P"/home/marc/work/lisp/play/issue-148.lisp":

debugger invoked on a DEFCONSTANT-UNEQL in thread
#<THREAD "main thread" RUNNING {10010A0113}>:
  The constant IMMUTABLE-GLOBAL-VAR is being redefined (from "immutable" to
  "immutable")
See also:
  The ANSI Standard, Macro DEFCONSTANT
  The SBCL Manual, Node "Idiosyncrasies"

Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL.

restarts (invokable by number or by possibly-abbreviated name):
  0: [CONTINUE] Go ahead and change the value.
  1: [ABORT   ] Keep the old value.
  2: [RETRY   ] Retry EVAL of current toplevel form.
  3:            Ignore error and continue loading file "/home/marc/work/lisp/play/issue-148.lisp".
  4:            Abort loading file "/home/marc/work/lisp/play/issue-148.lisp".
  5:            Exit debugger, returning to top level.

(SB-IMPL::%DEFCONSTANT IMMUTABLE-GLOBAL-VAR "immutable" #S(SB-C:DEFINITION-SOURCE-LOCATION :NAMESTRING "/home/marc/work/lisp/play/issue-148.lisp" :INDICES 65536) NIL)
0
t

The exact same work-around applies in this case.

So even without whatever is causing this problem you would have to restart VSCode or execute the Developer: Reload Window command to get a new REPL each time you wanted to reload the file without this error.

[nobody-famous]

I have a bunch of bug fixes I'm working on, so I'll add this in. The main problem is that because... lisp... it's not possible to compile a file without affecting the running image. Attempting to compile the file to generate the diagnostics complains about stuff already being defined. The other annoying messages, from defpackage, defmacro, etc, are filtered out. Apparently this one is still getting through. I'll add it to the filters so that it stops complaining about it.

[madkins23]

That's pretty much what I was thinking. From there I went to "maybe spin up a separate REPL just for diagnotics" and then "but that would be a lot of work."

[nobody-famous]

I originally wanted to do the diagnostics by forking and doing the compile against the child process. That wasn't possible, though. SBCL only supports fork on unix and only if there's a single thread. The only thing I can think of that would actually work would be to have the main process dump its image to a file, start up another process that loads that image, and compile against that process. Doing that multiple times a second seems like a bad idea, though. :-)

[lewisl]

Bunch of Stack Overflow posts basically state that defconstant is broken in sbcl because of strange workarounds for undefined behavior. Recommendations are to simply not use it. Perhaps adopt a convention within your team to not change things defined in ALLCAPS.

Not true immutability by a long shot, but if workarounds are required for something so basic, it's not up to Alive to fix it. Either SBCL devs need to fix it or declare that they don't care--given that the problem has existed for years. Not exactly stellar engineering practice, but--hey--they're volunteers.

[metaleap]

@doongjohn what's the editor font in your OP screenshot above? Thanks =)

[doongjohn]

@metaleap It's Iosevka.