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

[Davis Herring]

[I'm back from vacation; a few already-old threads caught my eye.]

> > (defun f (a b) (list a b))
> >
> > (defalias 'g (apply-partially #'f 1))

[...]

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

Others have provided concrete examples already, but the point is that 
there's no clear distinction between "the wrapper(s)" and "the real 
code" so that `func-arity' could stop when it finished the one. 
Checking that the actual function-call step of evaluation (substitution 
of arguments, etc.) could succeed is not what is wanted in practice 
given functions like `apply-partially'.

Annotations could theoretically be added to indicate the boundary, but 
making them useful in the absence of evaluation would be non-trivial. 
(Even annotations that only worked during a true call could be useful to 
avoid ambiguities like those that inspire the ugly NotImplemented 
convention in Python.)

Lacking such wrapper analysis, if we accept the implementations of 
`apply-partially' and similar even though the function objects they 
return have the wrong signatures, we are making the statement that 
function signatures mediate between the Lisp programmer and the 
evaluator, not between programmers.  (Pretend that all functions are 
written "(defun pkg-f (&rest args) (apply 'pkg--f-impl args))".)  Put 
differently, functions as objects do not expose a "what is my interface" 
interface, but only the function call interface (buyer beware).  This 
interface-blindness can be useful: we _know_ that it makes no difference 
to the client that passes 2 arguments that it could have provided a 3rd 
&optional one.

One may choose instead to say that function signatures should be an 
accessible attribute.  But then `apply-partially' must be rewritten to 
examine the signature of the wrapped function (whose definition might 
change!) and to arrange to expose the correctly-reduced signature.  And 
we have to decide whether the signature data-type supported by the 
evaluator (x required + y optional arguments, where y may be infinite) 
is the one we wish to bless -- what if a function accepted any even 
number of arguments, for example?

Davis

--
This product is sold by volume, not by mass.  If it appears too dense or 
too sparse, it is because mass-energy conversion has occurred during 
shipping.