[Openmcl-devel] how to ignore this warning? - shadows standard CL definition.

[Gary Byers]

FWIW, 11.1.2.1.2.1 explicitly allows conforming programs to establish
lexical functional bindings of external CL-package symbols, provided
that the symbols in question don't have standardised definitions as
functions/macros/special operators.  So,

(flet ((*print-readably* () 'hi))  (*print-readably*))

is perfectly conforming (no matter how authoritative someone who tries
to tell you otherwise tries to sound.)

Shadowing (see section 3.1.5 for a similar use of the term
"shadowing"; if anyone seriously finds the warning's use of that term
inappropriate, then they'd presumably have the same reaction to a lot
of people's longstanding use of that term to describe what's going on
and may want to take issue with the glossary entry for "shadow" in
CLHS.  Ahem.)  Where was I ?

Ah, yes.  Code which violates the constraints listed in 11.1.2.1.2
(and which doesn't involve the exceptions listed in 11.1.2.1.2.1) is
non-conforming, the results of executing that code are undefined, and
for the last week or two in the trunk CCL has warned about attempts to
... um ... shadow standard CL definitions with local functions or macros.

Those undefined consequences that the warning's trying to call your
attention to can vary a lot: your example works as you expect it to in
CCL at the moment, but I'm not sure that it always has or always will
and I'm fairly sure that some ostensibly similar things might not
behave as anyone would expect.  There's probably a fairly wide
range of behavior across other implementations (including refusing to
compile the code at all.)  A fairly stern (non style-) warning seems
justified (even if it might be warning about something that might
happen to be harmless at the moment.)

I'm not sure that I'd want to encourage code like that in your example,
but I confess that I have mixed feelings about warning about it as well.
(If you know what you're doing and understand the issues, I lean toward
thinking that the compiler should shut up and get out of your way.) 
I'm certain that there are also cases where this (shadowing of a global
definition) is done inadvertently, and a warning in such cases is likely
preferable to having to debug a complex and subtle problem.

At first glance, something like:

(locally
   (declare (notinline +))
   (labels ((+ (&rest args) ...))
     ...))

looks like a pretty deliberate attempt to override the global definition
of +, and if things were changed so that the warning was suppressed in that
case I don't think that I'd feel too guilty about that (and you should just
quietly be given enough rope to maybe hang yourself.)

All of this is mostly just philosophical rambling.  The absolute best way
to avoid this warning (and to ensure that your code isn't depending on
arbitrary implementation-dependent behavior) is to not do what you're doing.


On Mon, 16 Apr 2012, ??? wrote:

> 
> [small-logo.png]
> I update to??1.9-dev-r15327M-trunk ?(DarwinX8664)!.
> 
> I sometime shadow standard cl function.
> 
> for example..
> 
> (defmethod plus ((p1 number) (p2 number))
> ? (+ p1 p2))
> 
> (defmethod plus ((p1 string) (p2 string))
> ? (concatenate 'string p1 p2))
> 
> (labels ((+ (&rest rest)
> ? (reduce #'plus rest)))
> ? (+ "clozure" " common" " lisp"))
> 
> 
> ;Compiler warnings :
> ; ? In an anonymous lambda form: Local function or macro name + shadows
> standard CL definition.
> => "clozure common lisp"
> 
> 
> 
> if I can ignore it, tell me what to do.... ? ?thank you.
> 
> 
> 
>