DEFVAR and DEFPARAMETER silently accept variable names not respecting the usual *naming-convention*.

[Jean-Philippe Paradis]

What I do:
(defvar unconventional-special-variable-name 42)
(defparameter unconventional-special-variable-name 42)

What happens:
No warning of any kind is signaled.

What I expected to happen:
I think a STYLE-WARNING would be appropriate.

I seem to remember that SBCL used to do this. I don't know if it's been removed intentionally for a good reason or if this is a regression.

(There's a similar issue with (let ((x 42)) (declare (special x))) but I wouldn't be surprised if tons of code didn't follow the usual *convention* for that, especially if the variable name is a gensym. Even the examples in the standard involving local special variables are like this.)

SBCL version: 1.0.42
uname -a: Linux dynamorph 2.6.32-27-generic #49-Ubuntu SMP Wed Dec 1 23:52:12 UTC 2010 i686 GNU/Linux

*features*:
(:SWANK :QUICKLISP :SB-BSD-SOCKETS-ADDRINFO :ASDF2 :ASDF :ANSI-CL :COMMON-LISP
 :SBCL :SB-DOC :SB-TEST :SB-LDB :SB-PACKAGE-LOCKS :SB-UNICODE :SB-EVAL
 :SB-SOURCE-LOCATIONS :IEEE-FLOATING-POINT :X86 :UNIX :ELF :LINUX :SB-THREAD
 :LARGEFILE :GENCGC :STACK-GROWS-DOWNWARD-NOT-UPWARD :C-STACK-IS-CONTROL-STACK
 :COMPARE-AND-SWAP-VOPS :UNWIND-TO-FRAME-AND-CALL-VOP :RAW-INSTANCE-INIT-VOPS
 :STACK-ALLOCATABLE-CLOSURES :STACK-ALLOCATABLE-VECTORS
 :STACK-ALLOCATABLE-LISTS :STACK-ALLOCATABLE-FIXED-OBJECTS :ALIEN-CALLBACKS
 :CYCLE-COUNTER :INLINE-CONSTANTS :MEMORY-BARRIER-VOPS :LINKAGE-TABLE
 :OS-PROVIDES-DLOPEN :OS-PROVIDES-PUTWC :OS-PROVIDES-SUSECONDS-T)

[Nikodemus Siivola (nikodemus)]

I agree in principle -- particularly after having been bitten by a package that shadowed DEFCONSTANT and replaced it with DEFPARAMETER -- but I think this is also going to be hated by some people very much.

So either this (and some existing ones) need a common superclass for easy muffling, like SB-EXT:STYLISTIC-WARNING or SB-EXT:BAD-STYLE-WARNING or something, or there needs to be a *WARN-ABOUT-STYLISTIC-ISSUES* toggle.

[Douglas Katzman (dougk)]

Conventions are usually enforced by external tools. The C world has clang-tidy, clang-format.
This doesn't belong in the compiler.

[Jean-Philippe Paradis (hexstream)]

I seem to remember that SBCL already throws warnings in various situations for various breaches of, technically, mere "conventions". This might be especially useful to newbies.

As just one example:

(setf my-undefined-variable 'whatever-value)

; in: SETF MY-UNDEFINED-VARIABLE
; (SETF MY-UNDEFINED-VARIABLE 'WHATEVER-VALUE)
; ==>
; (SETQ MY-UNDEFINED-VARIABLE 'WHATEVER-VALUE)
;
; caught WARNING:
; undefined variable: MY-UNDEFINED-VARIABLE
;
; compilation unit finished
; Undefined variable:
; MY-UNDEFINED-VARIABLE
; caught 1 WARNING condition
WHATEVER-VALUE

If I remember correctly, there is nothing in the standard that says you can't assign values to not previously declared variables, and as we all know, the (non-normative) examples in the CLHS do this extensively.

As I understand it, the convention of using "earmuffs" for special variables is about as strong as the convention of not assigning to undeclared variables, so I don't see why the former wouldn't throw a warning or style-warning while the latter does. And it's pretty clear to me that the latter is of great help to newbies, and implementing a warning or style-warning for the former would also be beneficial. (I've certainly seen newbies not use "earmuffs" when they're warranted non-zero times...)

PS: (Frankly I don't even remember what the effect of assigning an undeclared variable at the top-level is supposed to be, is the variable then a global non-special variable?? So I guess that assigning to undeclared variables is still even more harmful than not using "earmuffs" on special variables, but I think my point still stands. And I acknowledge that the warning about undeclared variables is very useful against typos even for non-newbies... But I think my point still stands. ;P)

---------------------------

Thanks very much for attending to (and usually fixing) tons of my old issues, btw!