bug#29786: 27.0.50; About the argument list of methods

[Stefan Monnier]

> It's not clear to me what the sentence saying the argument lists must
> all be identical tries to say.  Surely they can't all be identical when
> they need to specify different specializers?

All that matters is that they should all accept the same number of arguments.

> (cl-defmethod seq-mapn (function (stream stream) &rest streams)
>   "Map FUNCTION over the STREAMS.
>
> Example: this prints the first ten Fibonacci numbers:
>
>   (letrec ((fibs (stream-cons
>                   1
>                   (stream-cons
>                    1
>                    (seq-mapn #'+ fibs (stream-rest fibs))))))
>     (seq-do #'print (seq-take fibs 10)))
>
> \(fn FUNCTION STREAMS...)"

I think this "\(fn FUNCTION STREAMS...)" thingy doesn't make sense for
`cl-defmethod`: it only makes sense for `cl-defgeneric`.

> (cl-defmethod seq-mapn (function (sequence stream) &rest sequences)
>   "Map FUNCTION over the STREAMS.
[...]
>     (seq-do #'print (seq-take fibs 10)))"
[...]
> That gives me for C-h f:
>
> Implementations:
>
> (sequence (arg1 stream) &rest sequences) in 
> `~/software/elpa/packages/stream/stream.el'.

Oh, indeed, we have a bug in cl--generic-lambda:
We create a (cl-function (lambda (function stream &rest streams) ...)),
then macroexpand it, then retro-fit an additional `cnm` argument (the
implicit argument that holds the "next method", used by
cl-call-next-method).  But when we retro-fit this `cnm` argument, we're
not careful to update the potential (fn FOO) stuff added at the end of
the docstring.

Not sure how best to fix it,


        Stefan "who curses the idiot who came up with this gross (fn FOO) hack"