program-errors and invalid functions

[gb]

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.

[gb]

This - the general behavior of handling compile-time errors by creating invalid functions - affects the trunk and 1.2 branches as well as working-0711, even though there have been changes so that the invalid function accepts an indefinite number of arguments.

I believe that this behavior is totally wrong:

• I absolutely, positively do not want an existing, valid function definition to be overridden by an "invalid function" that results from a syntax or other error at compile-time.
• I want the opportunity to debug such errors in the context in which they occur; I do not want to have to guess what happened (or advise users to do so) based on what can be determined from the error string printed by the "invalid function."
• I run into this every few days, and find that it has a significant and negative impact on my productivity: the lisp is less usable for me as a result of this change, and I'm not exaggerating in saying that I've wasted hours because of this behavior. I would have to guess that other users and potential users get a similarly negative impression of CCL's usability.
• I can imagine that there are situations where being able to proceed after compilation errors when building a large system is also desirable and also improves usability. Having that functionality may be a good thing (and I understand that this was requested by a customer), but not all systems are built in the same way or in the same environment. Creating an "invalid function" as a means to recover from compile-time errors during batch-style compilation of a system that isn't "live" may be reasonable; hosing a live system (rather than entering a break loop) because of a syntax or other compile-time program error doesn't seem at all reasonable.
• We need to support both behaviors, but the distinction isn't just between COMPILE-FILE and interactive compilation. How errors are handled during compilation of a system (and to a much lesser extent during interactive compilation) depends on the nature of that system, on personal preferences, on programming culture and style, and on other factors. We have the unfortunate situation where a particular approach that's apparently appropriate for a particular customer's needs (where they typically build a large system in a bare lisp and not in an environment where that system is "live") limits (at least) my ability to interactively develop in the lisp, makes debugging harder, and likely negatively affects other users.

[gz]

This is fixed in the trunk by r9848 and in 1.2 by r9849. Not yet fixed in 0711.

[gz]

Now fixed in 0711 as well, by r9861.