From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Davis Herring Newsgroups: gmane.emacs.devel Subject: Re: Arbitrary function: find the number(s) of expected arguments Date: Mon, 18 Apr 2016 17:02:57 -0600 Organization: XCP-1 Message-ID: <571567A1.4070007@lanl.gov> References: <56E8906C.5050405@lanl.gov> <83egb68vfy.fsf@gnu.org> <87zituefp9.fsf@web.de> <83a8lu8srs.fsf@gnu.org> <87twk2ebp2.fsf@web.de> <838u1e8od1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1461020619 23843 80.91.229.3 (18 Apr 2016 23:03:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Apr 2016 23:03:39 +0000 (UTC) Cc: Michael Heerdegen , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Apr 19 01:03:23 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1asICO-0005Is-Mx for ged-emacs-devel@m.gmane.org; Tue, 19 Apr 2016 01:03:20 +0200 Original-Received: from localhost ([::1]:46788 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asICN-000643-M4 for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 19:03:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:32882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asIC8-0005zH-KT for emacs-devel@gnu.org; Mon, 18 Apr 2016 19:03:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asIC3-0000RF-Kg for emacs-devel@gnu.org; Mon, 18 Apr 2016 19:03:04 -0400 Original-Received: from proofpoint4.lanl.gov ([2001:400:4210:400::a4]:47462) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asIC3-0000R9-DO; Mon, 18 Apr 2016 19:02:59 -0400 Original-Received: from mailrelay1.lanl.gov (mailrelay1.lanl.gov [128.165.4.101]) by mailgate4.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id u3IN2v4P021177; Mon, 18 Apr 2016 17:02:57 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay1.lanl.gov (Postfix) with ESMTP id C06B013DE841; Mon, 18 Apr 2016 17:02:57 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay1.lanl.gov Original-Received: from frogger.lanl.gov (frogger.lanl.gov [128.165.123.154]) by mailrelay1.lanl.gov (Postfix) with ESMTP id A39EF13DE83F; Mon, 18 Apr 2016 17:02:57 -0600 (MDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <838u1e8od1.fsf@gnu.org> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-19_01:2016-04-18, 2016-04-18, 1970-01-01 signatures=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 2001:400:4210:400::a4 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:203076 Archived-At: [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.