Custom Query (1030 matches)

This was reported by Didier Verna on openmcl-devel a few times in the last week or so.

Compiling a file that contains

(defclass test-class (standard-class)
  ())

(defclass test ()
  ()
  (:metaclass test-class))

now errs at compile-time, apparently while doing a FIND-CLASS of TEST-CLASS while building the (new) class-keyvect.

This should already be fixed in r9331, but for the record and in case it rears its ugly head again.

The TYPED-FORM acode operation (basically, the acode representation of THE) now takes an extra argument indicating whether or not a runtime typecheck should occur; this is set to T by the frontend at high SAFETY levels. Historically, a TYPED-FORM acode operation was considered "simple and side-effect free" if its operand was and could therefore be evaluated out-of-order, but this is no longer true if typehecking is involved. (Since that typechecking can involve function calls and a lot of register shuffling, a typechecking TYPED-FORM should be viewed as something that has unknown side-effects and which can at least change register contents.)

in the working-0711 branch, the compiler traps certain kinds of compile-time PROGRAM-ERRORs (at least), WARNs about them, and produces a function that, when executed, complains about whatever errors were detected at compile-time.

? (defun bogus (x y) (eq x) y) ; misplaced paren
;Compiler warnings :
;   In BOGUS: Required arguments in (EQ X) don't match lambda list (FORM1 FORM2).
BOGUS

Unfortunately, the function that's created in this case takes 0 arguments; unless it's called with 0 arguments, one won't see the compile-time error reported.

When this happens when something is defined interactively, any previous (more) correct version of the function is quietly replaced with the 0-arg error-signaling version. Under the old behavior (where an error was signaled at compile-time), the old (presumably working) definition would have remained in place. With the new behavior, it may be necessary to reload code (if possible) and repeat a number of development steps to get back to the point where one has the opportunity to correct a simple syntax error. (I noticed this while working on the compiler, and find this aspect of the new behavior to be a big impediment to productivity.)

If this happens during COMPILE-FILE, I assume that the same sort of unfortunate side-effects occur (unless one is lucky enough to press ^{C before the binary is loaded.)}

I think that I understand some of the motivations for this change and hope that we can think of ways of satisfying the needs of all concerned parties.