Ticket #294 (closed defect: fixed)
program-errors and invalid functions
|Reported by:||gb||Owned by:||gz|
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.
- Priority changed from major to blocker
- Version changed from working-0711 to unspecific