[Openmcl-devel] Warning about unused arguments in generic function methods

[Hans Hübner]

The patch I sent certainly is not sufficient, as it fails to find
variables defined after the first lambda-list keyword (&rest, &key
etc).  I'll investigate some more and re-post.

-Hans

On Nov 14, 2007 1:34 PM, Hans Hübner <hans at huebner.org> wrote:
> Currently, you get a warning only for parameters that are implicitly
> specialized to the T class.  If you have an explicit specializer, no
> warning is generated:
>
> CL-USER> (defgeneric foo (a b))
> #<STANDARD-GENERIC-FUNCTION FOO #x300045AFEBDF>
> CL-USER> (defmethod foo ((a t) (b t)) t)
> #<STANDARD-METHOD FOO (T T)>
> CL-USER> (defmethod foo (a b) t)
>
> ;Compiler warnings :
> ;   Unused lexical variable A, in (FOO (T T)) inside an anonymous lambda form.
> ;   Unused lexical variable B, in (FOO (T T)) inside an anonymous lambda form.
>
> Following your suggestion, the following patch may do:
>
> Index: macros.lisp
> ===================================================================
> RCS file: /usr/local/tmpcvs/openmcl-dev/ccl/lib/macros.lisp,v
> retrieving revision 1.118
> diff -c -r1.118 macros.lisp
> *** macros.lisp 15 Oct 2007 04:10:54 -0000      1.118
> --- macros.lisp 14 Nov 2007 12:29:20 -0000
> ***************
> *** 1679,1685 ****
>             (when inner-list
>               (push `(declare ,@(nreverse inner-list)) inner)))))
>       (values (nreverse outer) (nreverse inner))))
> !
>
>   (defun parse-defmethod (name args env)
>     (validate-function-name name)
> --- 1679,1686 ----
>             (when inner-list
>               (push `(declare ,@(nreverse inner-list)) inner)))))
>       (values (nreverse outer) (nreverse inner))))
> !
> ! (defvar *DEFMETHOD-DECLARE-ALL-SPECIALIZED-ARGUMENTS-IGNORABLE* t)
>
>   (defun parse-defmethod (name args env)
>     (validate-function-name name)
> ***************
> *** 1708,1713 ****
> --- 1709,1716 ----
>                           (push `(type ,p ,(%car parameters)) types)))
>                        (t (signal-program-error "Illegal arg ~S" p))))
>                 (t
> +                (when *defmethod-declare-all-specialized-arguments-ignorable*
> +                  (push p refs))
>                  (push p parameters)
>                  (push t specializers-form)
>                  (push t specializers)))))
>
>
>
> On Nov 14, 2007 10:27 AM, Gary Byers <gb at clozure.com> wrote:
> > For a parameter specialized (implicitly or explicitly) to the
> > T class, it might be the case that that parameter is strictly
> > used for discrimination, but it's at least equally likely that
> > it's "just an argument".  For example:
> >
> > (defmethod stream-write-char ((s telnet-stream) char)
> >    s)
> >
> > I think that I would want a warning telling me that I'd forgotten
> > to reference CHAR; if I hadn't referenced S either ... well, it's
> > at least somewhat plausible that the specialized parameter was
> > used for discrimination only (though I think that I'd like to
> > know if I wrote a STREAM-WRITE-CHAR method that didn't reference
> > either of its arguments.)
> >
> > [If I actually -wanted- to ignore the character - as in
> >
> > (defmethod stream-write-char ((s null-stream) char)
> >    (declare (ignore char)))
> >
> > the IGNORE declaration doesn't seem too painful and seems to make the
> > intentional ignoring of the argument clear]
> >
> > It's certainly possible to think of examples where the failure to
> > reference a parameter that's specialized to the T class is in no way
> > anomalous (likely because such parameters were used solely for
> > discrimination.)  I can't think of a way for the compiler to guess
> > that when compiling a method body (or at least no way for it to guess
> > right consistently): that depends on contracts and conventions and (to
> > some extent at least) on coding style.
> >
> > It's not clear that method qualifiers change this significantly,
> > but I do wonder about cases like:
> >
> > (defmethod stream-write-char ((s some-stream-class) c)
> >    (call-next-method))
> >
> > since the 0-arg CALL-NEXT-METHOD arguably references the explicit
> > arguments.
> >
> > DEFMETHOD could macroexpand into something which declares all
> > required method arguments to be IGNORABLE (it currently does
> > that only for those things that're specialized to something
> > other than the T class), perhaps under the control of some
> > global variable (*DEFMETHOD-DECLARE-ALL-SPECIALIZED-ARGUMENTS-IGNORABLE*
> > or some such.)  I don't know how you'd know how to set that so
> > that you got warnings in cases like the STREAM-WRITE-CHAR but
> > not in the cases that you find annoying.
> >
> >
> >
> > On Wed, 14 Nov 2007, Hans Hübner wrote:
> >
> > > Hi,
> > >
> > > is there a way to make OpenMCL stop complaining about unused arguments
> > > in generic function methods?  I am fine with the warning in standard
> > > function definitions, but with methods it makes less sense because
> > > often, the arguments are present just to match the generic function
> > > signature and rightfully ignored.  This is especially true with
> > > :before and :after methods, where I find it very annoying to have to
> > > explicitly ignore unused arguments
> > >
> > > -Hans
> > > _______________________________________________
> > > Openmcl-devel mailing list
> > > Openmcl-devel at clozure.com
> > > http://clozure.com/mailman/listinfo/openmcl-devel
> > >
> > >
>