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:19:04 -0700 (PDT) Message-ID: <27c271fe-da82-4856-8d32-610235e89e78@default> 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: multipart/alternative; boundary="__1458929946685276469abhmp0017.oracle.com" X-Trace: ger.gmane.org 1458929989 30073 80.91.229.3 (25 Mar 2016 18:19:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 18:19:49 +0000 (UTC) Cc: Eli Zaretskii , emacs-devel@gnu.org To: Paul Pogonyshev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 19:19:37 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 1ajWKe-0002wt-GH for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 19:19:36 +0100 Original-Received: from localhost ([::1]:57412 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWKd-0002xD-Lk for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 14:19:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41906) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWKM-0002x1-5r for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:19:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajWKK-0006t9-RQ for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:19:18 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:16428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWKG-0006sO-03; Fri, 25 Mar 2016 14:19:12 -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 u2PIJ7Gp030162 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 18:19:07 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id u2PIJ6tR030490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 25 Mar 2016 18:19:07 GMT Original-Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u2PIJ6R9030821; Fri, 25 Mar 2016 18:19:06 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: 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:202237 Archived-At: --__1458929946685276469abhmp0017.oracle.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable (Please use plain-text for this mailing list from now on. I won't bother tr= ying to convert the formatting this time.) =C2=A0 > IIUC, you _cannot_ use `func-arity' to test whether something > is a subr. Yes, but you can and should use `subrp' for that. Of course you can. But that's irrelevant here. This is about what `subr-ari= ty' does. Its behavior is not the same as `func-arity' for a non-subr. If w= e are not deprecating `subr-arity' then it is not enough to send users to t= he doc for `func-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'. I understood it as argument against aliasing `subr-arity' to the new function: this can break _existing_ code if it relies on the fact that `subr-arity' signals an error when called with anything, but builtin. Yes. And? The same argument applies to just having its doc string tell users to use `= func-arity'. That might not break existing code, but it breaks the doc stri= ng. It no longer says what function `subr-arity' does. And it gives the fal= se impression that `func-arity' does the same thing. In fact, `func-arity' = does something different if the arg is not a subr. > This is a step backward.=C2=A0 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. I personally don't see why we need two functions for this. So, I would deprecate `subr-arity', but keep it around for backward compatibility. I personally feel the opposite - see my argument about not breaking existin= g code. But if that will be the decision then that's different. So far, the= re has been no decision to deprecate `subr-arity', AFAIK. On the other hand, I don't really care. All I want is that there is `func-arity' that works for _any_ function. I'm not attached to anything in the patch and as long as `func-arity' works, `func-arity' works for any function. So your want is satisfied. However, obtaining your want at the expense of also breaking a doc string i= s not right. feel free to change anything. I'm not going to change the broken doc string. But I certainly hope that so= meone will. When code is improved, if that change entails needing to change the doc, th= en the doc should be updated appropriately. --__1458929946685276469abhmp0017.oracle.com Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

(Ple= ase use plain-text for this mailing list from now on. I won't bother trying= to convert the formatting this time.)

 

> IIUC, you _cannot_ use `= func-arity' to test whether something

> is a subr.

Yes, but you can and should use `subrp' for that.

Of course you = can. But that's irrelevant here. This is about what `subr-arity' does. Its = behavior is not the same as `func-arity' for a non-subr. If we are not depr= ecating `subr-arity' then it is not enough to send users to the doc for `fu= nc-arity'.

> IOW, I am repeating the same argument I made before, w= hen

> I said that `subr-arity' should not be deprecated and

=

> simply repl= aced by `func-arity'.

I understood it as= argument against aliasing `subr-arity' to

the new function: this can break _= existing_ code if it relies

on the fact that `subr-arity' signals an error wh= en called with

anything, but builtin.

Yes. And?

The same argument appli= es to just having its doc string tell users to use `func-arity'. That might= not break existing code, but it breaks the doc string. It no longer says w= hat function `subr-arity' does. And it gives the false impression that `fun= c-arity' does the same thing. In fact, `func-arity' does something diffe= rent if the arg is not a subr.

> This is a step backward.&= nbsp; Unless we are really deprecating

> and replacing it, we should docum= ent `subr-arity' properly,

> as before, with the addition of cross-ref to = see `func-arity',

> stating that it handles any type of function.

I personally don't see why we need two functions= for this.

So, I would deprecate `subr-arity', but keep it around for

backward = compatibility.

I personally feel the opposite - see my argument about not br= eaking existing code. But if that will be the decision then that's differen= t. So far, there has been no decision to deprecate `subr-arity', AFAIK.

On the other hand, I don't really care. All I want is that there

is `func-a= rity' that works for _any_ function. I'm not attached

<= div>

to anything in the patc= h and as long as `func-arity' works,

`f= unc-arity' works for any function. So your want is satisfied.

However, obtaining your want at the expense of also breaking a doc stri= ng is not right.

feel free to change anything.=

I'm not going to change the broken doc string. But I certainly= hope that someone will.

When code is improved, if that change entail= s needing to change the doc, then the doc should be updated appropriately.<= o:p>

--__1458929946685276469abhmp0017.oracle.com--