From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Predicate for true lists Date: Sun, 8 Jul 2018 10:42:48 -0700 (PDT) Message-ID: 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> <194e1b99-dd46-0a72-c0e5-f88f1b0d65c2@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1531071660 29715 195.159.176.226 (8 Jul 2018 17:41:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jul 2018 17:41:00 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert , Eli Zaretskii , "Basil L. Contovounesios" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jul 08 19:40:56 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 1fcDg7-0007dx-SJ for ged-emacs-devel@m.gmane.org; Sun, 08 Jul 2018 19:40:56 +0200 Original-Received: from localhost ([::1]:37737 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcDiE-00049f-VE for ged-emacs-devel@m.gmane.org; Sun, 08 Jul 2018 13:43:06 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59790) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fcDi8-00049P-NP for emacs-devel@gnu.org; Sun, 08 Jul 2018 13:43:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fcDi7-0003JF-LZ for emacs-devel@gnu.org; Sun, 08 Jul 2018 13:43:00 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:39558) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fcDi3-0003Gb-OB; Sun, 08 Jul 2018 13:42:55 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.22/8.16.0.22) with SMTP id w68HgpNR108741; Sun, 8 Jul 2018 17:42:51 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2018-07-02; bh=6L5o5LkM9CcC5VdPVOp1t7x7aIqfXtkaK69kbU3+cMM=; b=BW/2+fOlOHF9NfCqD2b2jykA28hL9X4TflOBuGWAtnK4aGXkhd6FHq/8sAGme1dX3ca7 x2L/3evPtA1APWCDBOLc8Ob32jWbZSylboScaIvbKl/5yVytm+LJmiAurXj0Muo93red AGp2K/E4KRrjaU9UcId/ydwd7tHlwbCa9MQTmPC1CiB4xymwr3U5tTdn4fiffTEPn/ZE y0sWXTtsFAKDXnBRzVVp5KyKBfxzns9r1VLGtPcrtJQHmPr72nw3aCnUZPGnqMJOcOng eGCDOyvWYgXqFJ9hV4GkMUdzcIOaYYg/oPdqZDr+KBxNOwrBjHT+qqcsEdm4yLdLMCIc sg== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2k2p75hwwu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 08 Jul 2018 17:42:51 +0000 Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w68Hgox8022234 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 8 Jul 2018 17:42:50 GMT Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id w68Hgnvh019651; Sun, 8 Jul 2018 17:42:49 GMT In-Reply-To: <194e1b99-dd46-0a72-c0e5-f88f1b0d65c2@cs.ucla.edu> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4705.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8947 signatures=668705 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=567 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807080213 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.79 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:227117 Archived-At: >> 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 behavior when given a value of the wrong type, > there is greater leeway for extension in the future. I've already made my argument. By your reasoning, backward compatibility is a legalistic thing that depends on doc, not behavior. By mine, it's about compatible behavior, not just how well the behavior matches the doc. By your reasoning, providing no doc at all means there is no possibility of backward incompatibility! =20 If a faithful design spec is available then backward compatibility can also be said to be about compatible design changes (which is why I said "intended" behavior). But a faithful design spec makes clear (explicitly or implicitly/logically), the parts that are undefined (bottom). When a design change occurs that is not compatible (same behavior models, or a subset), backward incompatibility results. Whether the change is worth that incompatibility is a design decision. And there is a difference between a faithful design spec and doc. See previous reply, about judgments whether this or that behavior aspect should be documented. Some backward incompatibility may be inconsequential for some, or all, users - it depends. There's a difference between the existence of backward incompatibility and whether or how much users might complain (or even notice). For Emacs development, making design choices that change behavior includes deciding when a backward-incompatible change is worth it. A design choice is not based just on what the doc has said (does the doc give us enough "leeway"?). Doc is a user aid. Doc is neither the design nor the behavior that the design represents. Mixing these things up as you've done, and tossing out condescension about "elementary software engineering", doesn't help.