[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Davis Herring
Subject: Re: Arbitrary function: find the number(s) of expected arguments
Date: Mon, 18 Apr 2016 17:02:57 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0

[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?


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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]