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

[Eli Zaretskii]

> From: Michael Heerdegen <address@hidden>
> Cc: address@hidden
> Date: Sat, 19 Mar 2016 16:20:41 +0100
> 
> Eli Zaretskii <address@hidden> 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.

It will only do that if people don't quite understand what they are
doing.  I don't think we should assume our users will do that.

> 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.

But Emacs itself clearly _knows_ that only one argument is acceptable.
So a function that replicates the steps made by the Lisp interpreter
to arrive at this conclusion will be able to reach the same
conclusion.  So I don't see any insoluble problems here.

> 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).

I don't see how you reach this conclusion, except if you consider
faulty implementations.

> > > 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.

When an advice has been installed, that is already known, isn't it?

Once again, how does Emacs know?

> > > 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.

But it covers only a part of the turf.  So nothing bad will happen if
we enlarge the turf a bit, right?

> 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).

Triggering an exception only answers a yes/no question, which is not
necessarily what is needed.  It is also a terribly inelegant solution,
IMO.