(let ((S 0)
(R 1))
(declare (ignore R))
some-code)
If some-code contains a reference to R, SBCL complains thats an
ignored variable is being read - which is to say, SBCL isn't ignoring
R :)
If I remove the ignore and some-code doesn't contain a reference to R,
SBCL complains about an unused variable.
Is there a way to REALLY ignore R? I.e. don't complain about
references to it, or lack there of?
Or is this an SBCL - specific thing where I have to turn off warnings?
Can I turn off just this particular warning?
On Mar 19, 7:19 am, "Mike G." <···············@gmail.com> wrote:
> (let ((S 0)
> (R 1))
> (declare (ignore R))
> some-code)
>
> If some-code contains a reference to R, SBCL complains thats an
> ignored variable is being read - which is to say, SBCL isn't ignoring
> R :)
Ignore means do not diagnose the situation that a variable exists
without any references to it. If there are references, then that
situation isn't in effect. Moreover, CLHS says that it's desireable
for a compiler to diagnose a reference or special declaration of a
variable ignored by IGNORE.
> If I remove the ignore and some-code doesn't contain a reference to R,
> SBCL complains about an unused variable.
How did you miss IGNORABLE? It appears together with IGNORE in the
same CLHS section.
Mike G. wrote:
> (let ((S 0)
> (R 1))
> (declare (ignore R))
> some-code)
>
> If some-code contains a reference to R, SBCL complains thats an
> ignored variable is being read - which is to say, SBCL isn't ignoring
> R :)
>
> If I remove the ignore and some-code doesn't contain a reference to R,
> SBCL complains about an unused variable.
>
> Is there a way to REALLY ignore R? I.e. don't complain about
> references to it, or lack there of?
>
> Or is this an SBCL - specific thing where I have to turn off warnings?
> Can I turn off just this particular warning?
Check the entry for the ignore declaration in the HyperSpec. There you
will see that there is also an ignorable declaration which does what you
want.
Pascal
--
1st European Lisp Symposium (ELS'08)
http://prog.vub.ac.be/~pcostanza/els08/
My website: http://p-cos.net
Common Lisp Document Repository: http://cdr.eurolisp.org
Closer to MOP & ContextL: http://common-lisp.net/project/closer/
From: Kent M Pitman
Subject: Re: How to REALLY ignore a variable?
Date:
Message-ID: <u63viwa5p.fsf@nhplace.com>
"Mike G." <···············@gmail.com> writes:
> Is there a way to REALLY ignore R? I.e. don't complain about
> references to it, or lack there of?
Others have already mentioned IGNORABLE.
I'll just add the obvious which we used for years before that.
How to ignore it? Use it.
(defun f (x y)
x ; ignored
y)
In fact, the LispM used to define a function called IGNORE for this purpose.
You might wonder why a function? Well, let's define it and see. I'll call
it MOSTLY-IGNORE rather than IGNORE because (a) it doesn't really ignore the
value and (b) you aren't permitted to define IGNORE because it's a CL symbol.
(proclaim '(inline mostly-ignore))
(defun mostly-ignore (&rest things)
things ; ignored
nil)
In that way, you can do:
(defun f (x y)
(mostly-ignore x)
y)
The advantage of this is that you can also do:
(loop for x from 1 to 10 do (mostly-ignore x))
since you can't do
(loop for x from 1 to 10 do x)
Error: Unknown LOOP keyword: X
(loop for x from 1 to 10 do (declare (ignore x)))
Error: A DECLARE expression was seen where not permitted.
You can also map it and other such things.
(defvar *processor* 'mostly-ignore)
(defun process (things)
(mapc *processor* things))
You could use IDENTITY here, but that might confuse someone into thinking
you were doing something for value. IGNORE (or my MOSTLY-IGNORE substitute)
is more perspicuous.
In article <·············@nhplace.com>,
Kent M Pitman <······@nhplace.com> wrote:
> "Mike G." <···············@gmail.com> writes:
>
> > Is there a way to REALLY ignore R? I.e. don't complain about
> > references to it, or lack there of?
>
> Others have already mentioned IGNORABLE.
>
> I'll just add the obvious which we used for years before that.
> How to ignore it? Use it.
>
> (defun f (x y)
> x ; ignored
> y)
IIRC, the reason we created the IGNORABLE declaration was because there
were some implementations that would optimize out the meaningless
toplevel variable references, and then complain that the variables
weren't being used.
> (proclaim '(inline mostly-ignore))
> (defun mostly-ignore (&rest things)
> things ; ignored
> nil)
The same problem could happen with an inline function, since the
optimization would happen after merging in the function code. So if you
really wanted to convince those implementations that you were using the
variable, you had to use a non-inline function like this.
IGNORABLE was a much cleaner solution.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
From: Kent M Pitman
Subject: Re: How to REALLY ignore a variable?
Date:
Message-ID: <u63vhqwuo.fsf@nhplace.com>
Barry Margolin <······@alum.mit.edu> writes:
> > I'll just add the obvious which we used for years before that.
> > How to ignore it? Use it.
> >
> > (defun f (x y)
> > x ; ignored
> > y)
>
> IIRC, the reason we created the IGNORABLE declaration was because there
> were some implementations that would optimize out the meaningless
> toplevel variable references, and then complain that the variables
> weren't being used.
It's possible. But my recollection is just the oppposite--that this
technique continued to be far more usable for years after we put
IGNORABLE into dpANS CL because a number of vendors didn't get to
implementing IGNORABLE (or implementing it correctly), and because
this idiom was widely recognized and accepted.
It's not meaningless by any stretch of the imagination. It's just
unnecessary. And compilers are for managing such.
> > (proclaim '(inline mostly-ignore))
> > (defun mostly-ignore (&rest things)
> > things ; ignored
> > nil)
>
> The same problem could happen with an inline function, since the
> optimization would happen after merging in the function code.
If so, IMO, those were incorrect optimizations. Because they already
had to handle:
(proclaim '(inline inline-sample))
(defun inline-sample (x y z)
(cond (x y) (t z)))
where the usage was:
(inline-sample t a b)
and where the correct inline expansion was
(cond (t a) (t b))
which was going to optimize further to just
a
and which would then not reference b. So mostly anyone doing inline
reference had already confronted this; anyone not interested in this
problem would probably not inline things in the first place, I think.
And anyway, were the language to cater to such compilers, it would
have just "enabled" a bad behavior rather than encouraging a correct
one. This behavior was the right behavior independent of the issue of
handling variables declared ignorable or variables literally used in
unreachable places.
> So if you really wanted to convince those implementations that you
> were using the variable, you had to use a non-inline function like
> this.
Well, the implementation was always free to ignore the INLINE declaration,
and then it just looked like a trivial to a function that immediately
returned.
> IGNORABLE was a much cleaner solution.
I think it's a fine declaration to have. But I would have liked
the functional form, too.