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 11:31:56 -0700 (PDT) Message-ID: <15a8c8dd-a2f6-4dda-b446-13db174726fb@default> References: <56E8906C.5050405@lanl.gov> <83y49e731p.fsf@gnu.org> <83pouj0wx8.fsf@gnu.org> <834mbu1mp6.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 1458930759 10556 80.91.229.3 (25 Mar 2016 18:32:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 18:32:39 +0000 (UTC) Cc: pogonyshev@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 19:32:26 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 1ajWX2-0001XI-Pj for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 19:32:25 +0100 Original-Received: from localhost ([::1]:57460 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWX1-0005ZU-JJ for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 14:32:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44425) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWWm-0005ZP-9Z for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:32:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajWWl-0001qY-B5 for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:32:08 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:21407) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWWh-0001nx-Bm; Fri, 25 Mar 2016 14:32:03 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u2PIVwQ3010653 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 18:31:59 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2PIVwOw025410 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 18:31:58 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id u2PIVvUQ015519; Fri, 25 Mar 2016 18:31:57 GMT In-Reply-To: <834mbu1mp6.fsf@gnu.org> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:202239 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. >=20 > It isn't. It is, IMO. > > IIUC, you _cannot_ use `func-arity' to test whether something > > is a subr. >=20 > You have subrp for that; using subr-arity for this purpose borders > on the ridiculous. It's certainly unclean. Doesn't matter. The doc string of `subr-arity' should be faithful to what it does. Unless we deprecate it in favor of `func-arity', it is incorrect to pretend that the doc for `func-arity' describes the behavior of `subr-arity'. I never said that one should use `subr-arity' in place of `subrp'. I said only that `func-arity' does not give you the behavior of `subr-arity'. The doc for the latter should say what it does. > > 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'. >=20 > You were wrong then, and you are wrong now. You were wrong then, and you are wrong now. Naahhh. Deprecate `subr-arity' and there will be no problem with having the doc string of `subr-arity' just send users to the doc of `func-arity'. In that case, the only concern is breaking existing code, but that is often the case when deprecating something. Just deprecate it - no problem. > > 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')? >=20 > Because you objected, and I'd rather not start yet another > endless discussion. No, I did _not_ object to deprecating it. I only pointed out that you were wrong in saying that by aliasing you would be providing backward compatibility. This is what I said: Ignoring all the rest... (NB that part. I pointed to a problem with _one_ thing you said.) This sounds wrong to me. Just calling the new code (which I have not looked at, but which I presume does for arbitrary functions what `subr-arity' does for primitives) would NOT provide backward compatibility, precisely because it would (presumably) NOT have the same behavior as `subr-arity' for non-primitives - it would not raise an error. And that is the case. Just aliasing to `func-arity' would NOT provide backward compatibility. Nothing wrong with deprecating `subr-arity'. What was wrong was your claim that aliasing will provide backward compatibility.