Re: Arbitrary function: find the number(s) of expected arguments

[Michael Heerdegen <michael_heerdegen@web.de>]

Eli Zaretskii <eliz@gnu.org> writes:

> Do you have a better solution to suggest?  If so, let's hear it.

Not really.  The better solution would be that people should try to
avoid that situation.  This is not always possible, yes, but introducing
`fun-arity' would give a false appearance semblance reliability.

For example:

> > (defun f (a b) (list a b))
> > 
> > (defalias 'g (apply-partially #'f 1))
> > 
> > what would (func-arity 'g) return?
>
> Ideally, it should return (1 . 1).

This signature can be interpreted as "accepts any number of arguments",
whereby it doesn't.  The condition-case solution with the wrong number
of args handler at least also catches this case.

The problem with `func-arity' is that, as in the above example, can
return something that doesn't answer the question we talk about: "can
this function be called with these number of elements (e.g.)".  So it
only solves your problem if you are lucky (lucky at runtime).

> > What would it return for adviced functions?  An advice can change the
> > arity of a function.  Most do not, but most advices have an &rest args
> > signature.  Any function can be adviced.
>
> If the solution handles this complication, then it will return an
> accurate result.  If not, it will be a known limitation.

That's the problem: we can't handle this generally, since it can't be
known if and how an arbitrary advice calls the original funciton.

So after calling `func-arity' you still can't be sure whether a call
with a certain number of args or not.  That's not helpful.

> > My question is if it is a good idea to invite users to rely on
> > something like `func-arity'.
>
> You could ask the same about subr-arity, couldn't you?  And yet we do
> have it.

A subr is constant.  If you wrap it into another function, the result is
not a subr anymore.  So the result is at least more meaningful.


Hmm, A bit more reliable maybe (didn't think about it) would be
something semantically similar to

(condition-case nil
  (funcall function arguments ....)

 (wrong-number-of-arguments alternative-code ...))

that would catch "wrong-number-of-arguments" only at "top level" (which
would include calling the original function when FUNCTION is adviced,
but not function calls in the body of FUNCTION).


Michael.