[Sbcl-help] trouble with compiler

[Don Cohen]

This one a long time to figure out.
I was getting errors like this:
; caught ERROR:
; during macroexpansion of (LOOP FOR (Y Z) ...). Use *BREAK-ON-SIGNALS* to
; intercept.
;
; The value
; NIL
; is not of type
; (MEMBER T)

I don't understand why the error is caught. This seems to only make
debugging more inconvenient. But that's a side issue.

It turns out that this (member t) came from the following definition:

;; bootstrap (redefine later)
(defun need-read-lock-desc(desc) t)

The macroexpansion mentioned in the error message was calling a
function that called need-read-lock-desc, and that function ended up
checking that the result of its call to need-read-lock-desc was of
type (member t), And that didn't work after the later redefinition.

BTW, this type check did not appear when I loaded the source file,
only when I loaded the result of compile-file. And it did not appear
when the definition (of the caller) was copied to a subsequent file,
even when that file was compiled, so I guess it's the fact that the
two functions appeared in the same file being compiled that caused the
compiler to do this.

Is this even allowed by the spec? It certainly violates my
expectations. Whenever I redefine a function do I have to recompile
all of its callers? What am I supposed to do in order to use a
temporary bootstrap definition?



_______________________________________________
Sbcl-help mailing list
Sbcl...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sbcl-help

[Douglas Katzman via Sbcl-help]

Is the redef in the same file? If so, that's undefined behavior.

If different file, it's related to https://bugs.launchpad.net/sbcl/+bug/1393302 and https://bugs.launchpad.net/sbcl/+bug/1423418

[Don Cohen]

Douglas Katzman via Sbcl-help writes:
> Is the redef in the same file? If so, that's undefined behavior.
> If different file, it's related to
> https://bugs.launchpad.net/sbcl/+bug/1393302 and
> https://bugs.launchpad.net/sbcl/+bug/1423418

It was a different file, and yes I see that this is the same bug as
described in those pages. I guess I should be happy that it's
considered a bug and might eventually be fixed.

But even in the same file I find this counterintutitive.

I see now in hyperspec 3.2.2.3

A call within a file to a named function that is defined in the same
file refers to that function, unless that function has been declared
notinline.

Suggesting that if I had declared the function notinline then maybe
everything would have been ok?

The consequences are unspecified if functions are redefined
individually at run time or multiply defined in the same file.

I hope that last part only applies to the case of the function defined
in the same file and not declared notinline.

This is at least a case where loading the source file and the compiled
file differ. (Not that I'd want loading the source file to result in
such type checks!)