Why warnings about unused keyword although (call-next-method) is used?
in [Lisp]
|
Prev: C interpreter in Lisp/scheme/python
Next: Why warnings about unused keyword although (call-next-method) is used?
From: Paul Griffioen on 13 Jun 2010 19:27 On Mon, 14 Jun 2010 00:41:51 +0200, Pascal Costanza wrote: > On 13/06/2010 20:24, Paul Griffioen wrote: >> >> Why do compilers warn about unused keyword in methods when (call-next- >> method) is used? For example when compiling >> >> (defclass some-class () ()) >> >> (defmethod foo ((object some-class) some-arg&key some-key) >> (call-next-method)) >> >> SBCL and LispWorks warn about keyword some-key (haven't tried other >> compilers). The keyword is passed to the next method so declaring it as >> unused seems wrong. And they don't warn about argument some-arg. >> >> Is there any reason for this? And is there a way to get rid of these >> warnings? > > If there is no need to use the keyword argument in the method body, it's > better to just omit it. You can just say this: > > (defmethod foo ((object some-class) some-arg &key) > ...) > > This doesn't work if the defgeneric form also mentions the particular > keyword argument in question, but maybe it shouldn't either, since it > doesn't seem to be necessary for all methods. > > The exact rules when you have to mention a keyword argument and when not > are in the HyperSpec in Section 7.6.5. Note that keyword arguments > require extra processing, so not mentioning them may be preferable. If > all else fails, (declare (ignore some-key)) always does the trick. > > > Pascal Thanks for the explanation and the reference. I didn't know these rules. In my case the keyword is mentioned in the generic function so I have to mention it in the method. I'm not sure if I want to remove the keywords in the generic function. Why do you say that the keyword doesn't seem necessary? I want the method to accept it but the default handling is sufficient. I was uncertain about an ignore declaration (or the ignorable that Raffael Cavallaro mentions) because the regular argument doesn't need it. Is such a declaration always valid? Because the keyword is used, although not visible. The declaration seems a bit strange when I read the code, but maybe I just have to get used to it. Paul
From: Pascal Costanza on 14 Jun 2010 08:06 On 14/06/2010 01:56, Tim Bradshaw wrote: > On 2010-06-14 00:27:52 +0100, Paul Griffioen said: > >> In my case the keyword is mentioned in the generic function so I have to >> mention it in the method > > I'm pretty sure you can say ... &key &allow-other-keys ... though this > may result in less checking in some cases You can also provide &rest but no &key - then you get the same effect that all keyword arguments declared in the defgeneric form are implicitly accepted by the method as well, but you don't accept just anything. The interactions between the different variants cover all important cases, although they seem a bit counterintuitive at first. Pascal -- 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: Thomas A. Russ on 14 Jun 2010 12:16
Pascal Costanza <pc(a)p-cos.net> writes: > 'ignore is good when you know you don't want to use the variable. If you > then happen to use it anyway, you will get a warning, which may be > helpful. > > 'ignorable is good when you don't care. I think this case occurs rarer > than 'ignore in manually written code, but can be very useful in macros > that generate function or method definitions. And also for the case the OP is describing. Especially since experience shows that different lisp implementations take different views on whether an argument is "used" when there are implicit uses such as CALL-NEXT-METHOD. And sometimes also with regard to the "use" of required arguments to generic functions. Some compilers will consider the method dispatch to be a use of a variable and others will not. So using IGNORABLE is a portable solution to suppressing warnings without the risk of generating the opposite warning in a different implementation. -- Thomas A. Russ, USC/Information Sciences Institute |