> > Newbies should know what happens when you define things at > > toplevel and wonder why things don't behave the same anymore. > > (I've been bitten by this many times when I just wanted to do > > something quick and named a variable X, which is also used on > > other code.) > > So you are saying that the PRESENCE of the warning means you are > safe, right? When you get the warning, you are declaring a new > special and therefore will not be affecting existing > definitions. Things will behave as they had. When you DON'T get the > warning, you may be setting a special defined elsewhere, and thing > might not behave the same anymore. > > I don't think newbies are going to follow that line of > reasoning. More likely, when they see a warning, they are going to > think they are doing something wrong. > > Maybe the warning should read, "Good choice of names, this special > isn't used elsewhere". ...I must be missing something! > > I think there is a real problem of a related sort elsewhere: > ~/> lisp -noinit > * (defun hello () dlkfj) > > HELLO > * > > ...Here, I wouldn't mind a warning that dlkfj is assumed special.
It would be a really bad idea to remove the warning about special variables. You could argue that CMUCL shouldn't create special variables when you do setf at the top level --- that is a sufficiently good argument that people have created a flag to make the behavior customizable. But if CMUCL is going to create special variables with setf, it should certainly warn about it. After all, just because you're not using a variable named "foo" when you create it at the top level with setf doesn't mean it won't pop up later. Another, practical reason is as follows. * (setf *gc-verbse* nil) Warning: Declaring *GC-VERBSE* special. NIL * Can you see what happened here? I tried to set *gc-verbose*, but mistyped it. I got a nice warning that I had done something I hadn't intended to. Then I can go back and properly type it in: * (setf *gc-verbose* nil) NIL * A number of times this has saved me from wondering why the thing I wanted to happen didn't happen. As far as your example, the "dlkfj" in your hello function is not a special variable, it's an undefined free variable. That's a different ball of wax. And you will get a warning if you compile: * (defun hello () dlkfj) HELLO * (compile 'hello) ; Compiling LAMBDA NIL: ; Compiling Top-Level Form: ; In: LAMBDA NIL ; (BLOCK HELLO DLKFJ) ; Warning: Undefined variable DLKFJ ; ; ; Warning: This variable is undefined: ; DLKFJ ; ; Compilation unit finished. ; 2 warnings HELLO NIL NIL * In actual development it's best to use an IDE like Ilisp or Slime (Slime is really good!) or even Hemlock. When you use one of them, you find yourself compiling everything incrementally and you can see the results on a function-by-function basis. When I try to develop without one of the above I feel like I've got one hand tied behind my back. It will let you easily compile everything so you can see the warnings and it will also (especially if you use Slime) hide most or all of the noise CMUCL will otherwise give you. -- Fred Gilham [EMAIL PROTECTED] || Progressive (adj): Value-free; tolerant; non-judgemental. E.g. traditional archery instruction methods spent tedious hours teaching the archer to hit a bulls-eye. Progressive methods achieved better results by telling the student archer to shoot in the manner he or she found most comfortable, then calling whatever the arrow hit the bulls-eye.
