From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= Newsgroups: gmane.emacs.devel Subject: Re: Arbitrary function: find the number(s) of expected arguments Date: Fri, 25 Mar 2016 14:28:12 -0400 Message-ID: <56F5833C.30702@gmail.com> References: <56E8906C.5050405@lanl.gov> <83y49e731p.fsf@gnu.org> <83pouj0wx8.fsf@gnu.org> <27c271fe-da82-4856-8d32-610235e89e78@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qatJJQRj4cWEsPXMKGHh4rgmTakABqI2i" X-Trace: ger.gmane.org 1458930526 6784 80.91.229.3 (25 Mar 2016 18:28:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Mar 2016 18:28:46 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 25 19:28: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 1ajWTL-0007m3-1i for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 19:28:35 +0100 Original-Received: from localhost ([::1]:57447 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWTK-0004md-1A for ged-emacs-devel@m.gmane.org; Fri, 25 Mar 2016 14:28:34 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43819) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWT4-0004mU-RR for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:28:19 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ajWT1-0001G5-Ln for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:28:18 -0400 Original-Received: from mout.kundenserver.de ([212.227.126.130]:58557) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ajWT1-0001Ep-C9 for emacs-devel@gnu.org; Fri, 25 Mar 2016 14:28:15 -0400 Original-Received: from [18.189.75.34] ([18.189.75.34]) by mrelayeu.kundenserver.de (mreue004) with ESMTPSA (Nemesis) id 0MOmdm-1aeamO0uoQ-00644t for ; Fri, 25 Mar 2016 19:28:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: <27c271fe-da82-4856-8d32-610235e89e78@default> X-Provags-ID: V03:K0:XxnRrLLz2OsjXEqCno8tq9SEkfTyKE80FA9Dp/msXZSPpUlX42S sF06MnFHVweilVgUeQsGbfCpv3dKjAXZ+3h7CRsub6Vg9kelDe1bMYNUfLf4IeeSNmuEOTv EAPL/v6CL+1JSgdLehZt65cGnJNoeT4EGkQjXGTZfmZGHqgtkJ79km2g57mw7ilFp4sDnq8 IZsK1VaAP8Rr7I/hRZv0Q== X-UI-Out-Filterresults: notjunk:1;V01:K0:avpx79JerSM=:eULcBgRChNxtxyRGQLxEB9 xTZSFHzIcA1E9D46iZxmL4pUvDdewRaivAlQHE4uT0bqZORiqdZ9ALGnBdvsF1V0YjL9QnzuG 8v20829SsUujDSfk22C4mn7eQToB1A9hNoRStyh6w57UVUhIYvOvRBFfgEWqnK9jW8XYiBVUm L9s3GXgROOaH8BI8poMaabpge3cml4w1VxjEuCovRs3IDl8WSskerZimqRDbzMMnfH4e+jA7g RWjlizW4ERrZdZSmyvBg17WIrc5Z1RRaU6kgy69Dqf8bKGYD1qvWNYebiMgkn0eGHSYV+2Nlt uS2bIS4nmI5JsyVURD5F0ZIUPphv9RKxbClP+jjHM2eTWWEBnw/xgYZgfhH0aX1DAlYQIxIWs 3Uip8qtbijDqxJNkGyPEYjf3ryHs2xnj23fZZIF0SG0kwotZREzfkWq2wc3xgmtKINbFvZfk1 xrPlh/oaEo0/Wt89tejJzpRGleMfmuP9uv/1UPqTq0RFJQSI7UBqcPWg/E8gnH3Ed22zLIeEZ HGIRHDp9smnbsEGzghOP5bDNPe1vRDHbt2FREc10FIwUIBxHR0jNF4vZi6tFrTKXqiiFYdLQg ivn2jmDynXIS77luC7IBOOnY5pmKHaddzRZJPM4Ztn8pGC0d9A3nGHY9MkrFdtNw0n1IsGOvK h4USkc8JJMxTiNPsfX/j52o0yUkbXvjI5s6aaYIQIy03qAXIb6bwHm4D2UKVG9s8mZnw= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 212.227.126.130 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:202238 Archived-At: This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --qatJJQRj4cWEsPXMKGHh4rgmTakABqI2i Content-Type: multipart/mixed; boundary="DuFD5SqdStC8GbTGR2oj8AgqrBLTBQkwk" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: emacs-devel@gnu.org Message-ID: <56F5833C.30702@gmail.com> Subject: Re: Arbitrary function: find the number(s) of expected arguments References: <56E8906C.5050405@lanl.gov> <83y49e731p.fsf@gnu.org> <83pouj0wx8.fsf@gnu.org> <27c271fe-da82-4856-8d32-610235e89e78@default> In-Reply-To: <27c271fe-da82-4856-8d32-610235e89e78@default> --DuFD5SqdStC8GbTGR2oj8AgqrBLTBQkwk Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Drew, your message is actually much harder to read in Thunderbird that th= e one you replied to. Maybe using a plain text response in such cases wou= ld be best? I had no trouble reading Paul's email, but yours was tricky. On 03/25/2016 02:19 PM, Drew Adams wrote: > (Please use plain-text for this mailing list from now on. I won't bothe= r trying to convert the formatting this time.) >=20 > =20 >=20 >> IIUC, you _cannot_ use `func-arity' to test whether something >=20 >> is a subr. >=20 > Yes, but you can and should use `subrp' for that. >=20 > 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= =2E If we are not deprecating `subr-arity' then it is not enough to send = users to the doc for `func-arity'. >=20 >> IOW, I am repeating the same argument I made before, when >=20 >> I said that `subr-arity' should not be deprecated and >=20 >> simply replaced by `func-arity'. >=20 > I understood it as argument against aliasing `subr-arity' to >=20 > the new function: this can break _existing_ code if it relies >=20 > on the fact that `subr-arity' signals an error when called with >=20 > anything, but builtin. >=20 > Yes. And? >=20 > The same argument applies to just having its doc string tell users to u= se `func-arity'. That might not break existing code, but it breaks the do= c string. It no longer says what function `subr-arity' does. And it gives= the false impression that `func-arity' does the same thing. In fact, `fu= nc-arity' does something /different/ if the arg is not a subr. >=20 >> This is a step backward. Unless we are really deprecating >=20 >> and replacing it, we should document `subr-arity' properly, >=20 >> as before, with the addition of cross-ref to see `func-arity', >=20 >> stating that it handles any type of function. >=20 > I personally don't see why we need two functions for this. >=20 > So, I would deprecate `subr-arity', but keep it around for >=20 > backward compatibility. >=20 > I personally feel the opposite - see my argument about not breaking exi= sting code. But if that will be the decision then that's different. So fa= r, there has been no decision to deprecate `subr-arity', AFAIK. >=20 > On the other hand, I don't really care. All I want is that there >=20 > is `func-arity' that works for _any_ function. I'm not attached >=20 > to anything in the patch and as long as `func-arity' works, >=20 > `func-arity' works for any function. So your want is satisfied. >=20 > However, obtaining your want at the expense of also breaking a doc stri= ng is not right. >=20 > feel free to change anything. >=20 > I'm not going to change the broken doc string. But I certainly hope tha= t someone will. >=20 > When code is improved, if that change entails needing to change the doc= , then the doc should be updated appropriately. >=20 --DuFD5SqdStC8GbTGR2oj8AgqrBLTBQkwk-- --qatJJQRj4cWEsPXMKGHh4rgmTakABqI2i Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJW9YM8AAoJEPqg+cTm90wjUUIP/jJNImATt+IAY43ueCmplPmK jUcu2XiAL1v0inoAMswJIuYTIBO4hSpGIjDkyfYYsj1o+rea7gWcpBhxE1PVL5Ki hp8T/f4At2wZPMMHejgB32KgElbhKbqcYITJo90BlFmVmVL5Wa0u3hjd0DF1jsXt AKmkhAHvUWUeRKRcog71nUf/Gc+coiiPH8toGUCnqpuMJE38RRJoiHmMo4EEvFmY eg9gwUiehq83Vwaknn947UaAD8B1IJLOVbNWUOz/Lkbjt1/1F+ScoUi6ZecfQrjF oyVdXjhGP4+zosZmZvAWY8KCKZpAE25LRlT1nFBoLS53ifaSo9laXodZrl52xdXJ 1rbNivwYmuys3vEeHIm41OMFCzK7acybZMELz74oTgWl5dibsMVMvcQZFU3dWXZa JYiTqngThVbWS+RyY0iXBkC22WmzMUq+GhnaOp9cX+rWT8fS5UUzbOPYdgN1RqG9 ovp/Z1rE+D/Rf1kwxJaD9PFW8DUdiTHuXjRUEgpIaW8kP+FmyVLVN1j6a82vPMtF dg3yN9LfjIg0u5goYF0iG6GuWkVZTRHbmaGOOWmMrRp70aE5CAwlKIeQVMubqO96 5XrMNulC/4ahGe5sI3WQVZ08CJpIgBUUg+1c6mnpqButoindUJaen2DwjYIowL4K 3QnvANoUAmD1kiu5pQZ5 =m5GT -----END PGP SIGNATURE----- --qatJJQRj4cWEsPXMKGHh4rgmTakABqI2i--