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 12:43:54 -0600 Organization: XCP-1 Message-ID: <57152AEA.10006@lanl.gov> References: < <56E8906C.5050405@lanl.gov> <<83y49e731p.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 1461005061 8317 80.91.229.3 (18 Apr 2016 18:44:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Apr 2016 18:44:21 +0000 (UTC) Cc: emacs-devel@gnu.org To: Drew Adams , Eli Zaretskii , Paul Pogonyshev Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 18 20:44:07 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 1asE9X-0007Ho-Af for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 20:44:07 +0200 Original-Received: from localhost ([::1]:43560 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asE9W-00089P-Gf for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 14:44:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60877) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asE9R-00084q-KZ for emacs-devel@gnu.org; Mon, 18 Apr 2016 14:44:02 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asE9O-0003Kp-Cm for emacs-devel@gnu.org; Mon, 18 Apr 2016 14:44:01 -0400 Original-Received: from proofpoint4.lanl.gov ([2001:400:4210:400::a4]:60259) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asE9O-0003Kf-56 for emacs-devel@gnu.org; Mon, 18 Apr 2016 14:43:58 -0400 Original-Received: from mailrelay2.lanl.gov (mailrelay2.lanl.gov [128.165.4.103]) by mailgate4.lanl.gov (8.15.0.59/8.15.0.59) with ESMTP id u3IIhsTU018994; Mon, 18 Apr 2016 12:43:54 -0600 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by mailrelay2.lanl.gov (Postfix) with ESMTP id AEB31F0B72B; Mon, 18 Apr 2016 12:43:54 -0600 (MDT) X-NIE-2-Virus-Scanner: amavisd-new at mailrelay2.lanl.gov Original-Received: from frogger.lanl.gov (frogger.lanl.gov [128.165.123.154]) by mailrelay2.lanl.gov (Postfix) with ESMTP id 905DCF0B72A; Mon, 18 Apr 2016 12:43:54 -0600 (MDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 In-Reply-To: X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.15.96, 1.0.3, 0.0.0000 definitions=2016-04-18_12: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:203060 Archived-At: [I'm back from vacation; a few already-old threads caught my eye.] > Any existing code that depends on an error being raised by > `subr-arity' would break. E.g., > > (condition-case err > (subr-arity 'foo) > (error (do-something))) This issue is that of undefined behavior: is (subr-arity 0) UB or is it defined to be an error? The doc string says simply "SUBR must be a built-in function." which is language typical of UB in some contexts, but Emacs doesn't explicitly have that notion to my knowledge. If it's UB, then your example is wrong already and its breakage is irrelevant. If the error is a defined part of the interface, then yes the change is incompatible. All kinds of interfaces are thoroughly defined only for a subset of cases, and it's as much as anything a cultural issue whether the (historical) implementation's behavior outside that set is sacrosanct or not. 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.