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: Sat, 7 Jul 2018 17:15:50 -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> 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 1531008854 9623 195.159.176.226 (8 Jul 2018 00:14:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 8 Jul 2018 00:14:14 +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 02:14:09 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 1fbxL6-0002O8-4S for ged-emacs-devel@m.gmane.org; Sun, 08 Jul 2018 02:14:08 +0200 Original-Received: from localhost ([::1]:35264 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbxNA-0005Iu-6w for ged-emacs-devel@m.gmane.org; Sat, 07 Jul 2018 20:16:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37002) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fbxN0-0005Ip-J6 for emacs-devel@gnu.org; Sat, 07 Jul 2018 20:16:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fbxMz-0004qw-Ja for emacs-devel@gnu.org; Sat, 07 Jul 2018 20:16:06 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:35948) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fbxMv-0004lR-OM; Sat, 07 Jul 2018 20:16:01 -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 w680DxXP103767; Sun, 8 Jul 2018 00:15:52 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=fKR9j+zIuVjsCQRJaUgECyDEF2Vccdv53FTGxskzzSI=; b=YZsWy0dBPwKBFOFS33dOJujvmfymtsLgJm7QOCHX9VTwP2CymGv33r/+vu38C1qyko/4 CjYkgHE4iZD1IVTDcv6khUbsjqoZwZG1iHEkLtjP/YUstnVVDsIsUnREFisecaoqGMm/ 23aU5/o1Bv89LB4c5QegwgU2z+n2ekhJMgdrmGxciGJcrzR7pT4zq10bkhHxI/Aos2g2 apB2w8eRiMaeQAkhQ5+dUMIp9L5eYosYx+7i/Tak3Ty0C6wYUwG5UqhPGermXT8RZ5un ErXIS+wHyqjW/oGLlehidQckkRCb66u6BzOT8C6s2o8MGpLg6oh9rDNHWtiPpEW1wPyI OQ== Original-Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp2130.oracle.com with ESMTP id 2k2p75h30c-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 08 Jul 2018 00:15:52 +0000 Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.14.4/8.14.4) with ESMTP id w680Fpff014451 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 8 Jul 2018 00:15:51 GMT Original-Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.14.4/8.13.8) with ESMTP id w680FnJl004901; Sun, 8 Jul 2018 00:15:50 GMT In-Reply-To: <17d4bfb6-4c14-901f-716f-4aa50386eb9d@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=716 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1807080002 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:227086 Archived-At: > The documentation for "*" doesn't say that "*" signals an error if an > argument is not a number or a marker; it says only that its arguments > are numbers or markers. This wording means that if we later extend "*" > (say, to support multiplication on vectors of numbers), we won't be > making an incompatible change. I'm sorry to butt in here, but I disagree. Such a change _is_ an incompatible change, _regardless_ of what the doc might say before the change. An incompatible change is about behavior, not just doc. If we at some point changed `*' so that it accepted also vectors and performed a dot- or cross-product operation (or something else), then that would be decided taking into account that the behavior (for vector arguments) changes. For vector arguments the change would, yes, be incompatible, regardless of what the doc might have said. Presumably, if such a decision were ever made, it would be a change for the better - but it would nevertheless an incompatible change. The point of view that we won't document what the current error-handling behavior is, in hopes that that will somehow give us more leeway for changing the behavior later, is misguided. Users should be able to count on the intended behavior - the design, not just what on some part of it that we choose to advertise. We should document the intended behavior, including the error behavior. If we later change the behavior, so be it. At that point we'll change the doc to fit the new behavior. We are all users of Emacs. Doc is a window into the behavior. There is no sense tinting it or blocking part of its view. I spoke of "intended behavior" and "design", as distinct from unintended behavior (e.g. bugs) and implementation details. Raising an error for an argument that is a vector is presumably part of the intended design.