From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Predicate for true lists Date: Sun, 8 Jul 2018 09:00:04 -0700 Organization: UCLA Computer Science Department Message-ID: <194e1b99-dd46-0a72-c0e5-f88f1b0d65c2@cs.ucla.edu> References: <87fu3vdjjk.fsf@tcd.ie> <87bmcqhhsf.fsf@tcd.ie> <87in6xgtpb.fsf@tcd.ie> <2af892df-26cb-60b2-4fd8-067fcb3d32e9@cs.ucla.edu> <87r2kh9uwx.fsf@tcd.ie> <83h8lcnbxb.fsf@gnu.org> <6fc589d1-2c21-3e9b-be47-b7700f61642d@cs.ucla.edu> <831scflefs.fsf@gnu.org> <5d0d79d3-6291-fbf0-1028-064f86787483@cs.ucla.edu> <837em7jrag.fsf@gnu.org> <87k1q7ytmr.fsf@tcd.ie> <83o9fjhvnk.fsf@gnu.org> <87efgfyomt.fsf@tcd.ie> <83k1q7ht51.fsf@gnu.org> <17d4bfb6-4c14-901f-716f-4aa50386eb9d@cs.ucla.edu> <6a48d13f-9d6b-f9a6-3b41-6ea0c8294d81@cs.ucla.edu> <3a8f5e42-99fd-4814-bbaf-de6f11866492@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531065652 20648 195.159.176.226 (8 Jul 2018 16:00:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jul 2018 16:00:52 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 Cc: emacs-devel@gnu.org To: Drew Adams , Eli Zaretskii , "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 08 18:00:48 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fcC7C-0005Ck-8S for ged-emacs-devel@m.gmane.org; Sun, 08 Jul 2018 18:00:46 +0200 Original-Received: from localhost ([::1]:37475 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcC9J-0004Ou-Fc for ged-emacs-devel@m.gmane.org; Sun, 08 Jul 2018 12:02:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35436) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcC6l-0002iF-7C for emacs-devel@gnu.org; Sun, 08 Jul 2018 12:00:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcC6k-0004oB-CL for emacs-devel@gnu.org; Sun, 08 Jul 2018 12:00:19 -0400 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:57532) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fcC6f-0004hp-Fd; Sun, 08 Jul 2018 12:00:13 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 133421605B0; Sun, 8 Jul 2018 09:00:11 -0700 (PDT) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 4HDGPpn61FEr; Sun, 8 Jul 2018 09:00:10 -0700 (PDT) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 3DBB216060E; Sun, 8 Jul 2018 09:00:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id j9u63PoaQx3k; Sun, 8 Jul 2018 09:00:10 -0700 (PDT) Original-Received: from [192.168.1.9] (unknown [47.154.30.119]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id D373B1605B0; Sun, 8 Jul 2018 09:00:09 -0700 (PDT) Openpgp: preference=signencrypt Autocrypt: addr=eggert@cs.ucla.edu; prefer-encrypt=mutual; keydata= xsFNBEyAcmQBEADAAyH2xoTu7ppG5D3a8FMZEon74dCvc4+q1XA2J2tBy2pwaTqfhpxxdGA9 Jj50UJ3PD4bSUEgN8tLZ0san47l5XTAFLi2456ciSl5m8sKaHlGdt9XmAAtmXqeZVIYX/UFS 96fDzf4xhEmm/y7LbYEPQdUdxu47xA5KhTYp5bltF3WYDz1Ygd7gx07Auwp7iw7eNvnoDTAl KAl8KYDZzbDNCQGEbpY3efZIvPdeI+FWQN4W+kghy+P6au6PrIIhYraeua7XDdb2LS1en3Ss mE3QjqfRqI/A2ue8JMwsvXe/WK38Ezs6x74iTaqI3AFH6ilAhDqpMnd/msSESNFt76DiO1ZK QMr9amVPknjfPmJISqdhgB1DlEdw34sROf6V8mZw0xfqT6PKE46LcFefzs0kbg4GORf8vjG2 Sf1tk5eU8MBiyN/bZ03bKNjNYMpODDQQwuP84kYLkX2wBxxMAhBxwbDVZudzxDZJ1C2VXujC OJVxq2kljBM9ETYuUGqd75AW2LXrLw6+MuIsHFAYAgRr7+KcwDgBAfwhPBYX34nSSiHlmLC+ KaHLeCLF5ZI2vKm3HEeCTtlOg7xZEONgwzL+fdKo+D6SoC8RRxJKs8a3sVfI4t6CnrQzvJbB n6gxdgCu5i29J1QCYrCYvql2UyFPAK+do99/1jOXT4m2836j1wARAQABzSBQYXVsIEVnZ2Vy dCA8ZWdnZXJ0QGNzLnVjbGEuZWR1PsLBfgQTAQIAKAUCTIByZAIbAwUJEswDAAYLCQgHAwIG FQgCCQoLBBYCAwECH In-Reply-To: <3a8f5e42-99fd-4814-bbaf-de6f11866492@default> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 131.179.128.68 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:227113 Archived-At: Drew Adams wrote: > I specifically distinguished between design (intended > behavior) and implementation (actual behavior, with bugs). That's a nonstandard distinction. The more normal distinction is that des= ign=20 covers the strategy for implementing what users want or need, and impleme= ntation=20 covers the details of what the code actually does. For now, let's simplif= y the=20 discussion by stipulating that this code is bug-free, as bugs are a red h= erring=20 here (nobody is asserting that 'length' has a bug). > My point was that not mentioning error-handling behavior > does _not_ make a future change less backward-incompatible. Your point was incorrect. If a function does not explicitly document its=20 behavior when given a value of the wrong type, there is greater leeway fo= r=20 extension in the future. Conversely, if a function's documentation goes o= ut of=20 its way to say explicitly that it signals an error for a wrong type, even= though=20 this is not common practice in function documentation, users will not=20 unreasonably conclude that there's something special about this function,= and=20 that it is not likely to be extended in the future in the same way that a= n=20 ordinary function would be extended. > It's a mistake to think or pretend that you're not breaking > backward compatibility just because the behavior you change > was never documented. No, it's not a mistake at all. Relying on undocumented behavior is more l= ikely=20 to lead to future bugs than not relying on undocumented behavior, and use= rs know=20 (or should know) this when they write their code. So, changing undocument= ed=20 behavior is less likely to break user code than changing documented behav= ior is.=20 This is all elementary software engineering. We should not base our work = on the=20 theory that any code change that alters machine instructions is "breaking= =20 compatibility" (the absolutist position), because that is too strict a no= tion of=20 "compatibility" to be of much practical use.