Comment 5 for bug 841260

"No, the REPL expressly avoids printing anything from the compiler to the extent possible."

Uh?!? To me, this seems like a strictly counter-productive policy.

1. Any gratuitous differences between evaluation in the REPL and other contexts are likely to lead to unnecessary surprises (for me and/or other people) later. If I'm testing code in the REPL, often with the view of copy/pasting that code in some other context when I'm satisfied, it's much better if the code behaves exactly the same in other contexts, to the extent possible.

2. The REPL is the perfect time to throw warnings at me, as I can trivially ignore them if I don't care about them.

"(setq fred 5) ; no defvar on this gets a warning
Most other implementations will *not* print "undefined variable", and it's wrong that we do."

What?!?

1. I don't know that anyone should ever use SETQ when SETF would do, which is virtually always.

2. I don't even know what "(setq fred 5)" even means if the "fred" binding has not yet been defined. Isn't that undefined or unspecified behavior or something like that? Is "fred" then a special variable without earmuffs?? Seems like a bad idea all around.

3. It seems to me to be a particularly good idea to throw a warning in this case, as SETQ (or SETF) on undefined bindings seems to be used almost exclusively by confused newbies, who should learn about properly defining bindings as quickly as possible. Properly using DEFVAR, DEFPARAMETER or LET has never seemed like a burden to me...