From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Arbitrary function: find the number(s) of expected arguments Date: Fri, 25 Mar 2016 09:35:20 -0700 (PDT) Message-ID: References: <56E8906C.5050405@lanl.gov> <83y49e731p.fsf@gnu.org> <83pouj0wx8.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1458923778 27419 80.91.229.3 (25 Mar 2016 16:36:18 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 16:36:18 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Pogonyshev , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 17:36:06 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 1ajUiT-0006s8-VW for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 17:36:06 +0100 Original-Received: from localhost ([::1]:57051 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajUiQ-0001oI-9Y for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 12:36:02 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45480) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajUi0-0001nH-Oz for emacs-devel@gnu.org; Fri, 25 Mar 2016 12:35:37 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajUhz-0000FR-OM for emacs-devel@gnu.org; Fri, 25 Mar 2016 12:35:36 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:22300) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajUhu-0000DI-5y; Fri, 25 Mar 2016 12:35:30 -0400 Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2PGZP17016470 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 16:35:26 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u2PGZOVj032298 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 16:35:25 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id u2PGZMFl026009; Fri, 25 Mar 2016 16:35:23 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: userv0021.oracle.com [156.151.31.71] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202231 Archived-At: > =C2=A0`subr-arity' is still in the documentation, but I replaced its > description with an advice to use `func-arity' instead. Again, that is wrong, IMO. IIUC, you _cannot_ use `func-arity' to test whether something is a subr. You can use `subr_arity' to give you the arity of a subr AND to raise an error if the argument is not a subr. The latter behavior is not available in `func-arity'. The proper doc for `subr-arity' is to say what it _does_, including that it raises an error for non-subr arg. Its doc can, and should, refer to `func-arity', but only as a way to test the arity of _any_ function - not as a recommended replacement for `subr-arity'. IOW, I am repeating the same argument I made before, when I said that `subr-arity' should not be deprecated and simply replaced by `func-arity'. If my argument is being rejected (in effect - in the new doc string) then why are we not doing that openly (deprecating `subr-arity' and replacing it with `func-arity')? Either `func-arity' is a proper replacement for `subr-arity' or it is not. (I think it is not.) If it is, then replace it properly. In addition, the new doc string for `subr-arity' also suffers from making readers work extra hard. They need to refer to the doc of `func-arity', not only for the general description of the behavior and each of the parameters, but also to understand the difference wrt symbol indirection. This is a step backward. Unless we are really deprecating and replacing it, we should document `subr-arity' properly, as before, with the addition of cross-ref to see `func-arity', stating that it handles any type of function. IOW, if you want the arity of an arbitrary function, you can use `func-arity' to get that. That's all.