From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Internationalize Emacs's messages (swahili) Date: Fri, 1 Jan 2021 14:55:49 -0800 (PST) Message-ID: <8e08cd0e-ce90-445c-82b6-3d93b254af59@default> References: <87o8ivumn5.fsf@telefonica.net> <86wnx8otoj.fsf@163.com> <834kkbp9vr.fsf@gnu.org> <87czyxuxw6.fsf@db48x.net> <87y2hlt82w.fsf@db48x.net> <87lfdlvsw4.fsf@logand.com> <83h7o8ncly.fsf@gnu.org> <87pn2wudab.fsf@db48x.net> <87mty0c3m1.fsf@gnus.org> <83czywnb86.fsf@gnu.org> <87im8ob707.fsf@gnus.org> <87eejcb6nx.fsf@gnus.org> <875z4ob5c9.fsf@gnus.org> <87a6u09nkq.fsf@gnus.org> <875z4o9jdg.fsf@gnus.org> <87r1nb8yoj.fsf@gnus.org> <892fac78-0457-41b4-a442-46d992ca6e23@default> <87czyo3dj1.fsf@logand.com> <181c8a83-fe72-4642-a9da-6972310510a8@default> <87k0sw1f9q.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30476"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , emacs-devel@gnu.org To: Tomas Hlavaty , Lars Ingebrigtsen , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jan 01 23:59:03 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kvTNv-0007qD-0M for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 23:59:03 +0100 Original-Received: from localhost ([::1]:52338 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kvTNu-0000Uu-1z for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Jan 2021 17:59:02 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42216) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvTMr-00085a-LC for emacs-devel@gnu.org; Fri, 01 Jan 2021 17:58:00 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:55586) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kvTMp-0005Hk-AN; Fri, 01 Jan 2021 17:57:56 -0500 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 101Mvndi066346; Fri, 1 Jan 2021 22:57: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-2020-01-29; bh=VPL9vAjv/c1V0RZbL6L9Vp+laOAXxmy6idjVYajOKuc=; b=XuSoDYOR/UKqGgj3LzMKfEpHggRBCHamAFvtGPB1bFDqtw7OR31YRa7jkNA86rBXMfN/ c4NmoSTbEuZ+5ju6Owxg46zyxMNPWILyYhEQJ0erwKDgmHiqN/+R48n1ySe1i4I9/+jb iTRpK5Q6tT2qR+otSkYu+7WrmfQEfcoThjcIoMFCb4qK4sCQkjKNJyWBgXA1iI9MuflI eWOS4NMeilqwdIaUCruLQkpKvqKXft9u6wg9ySqoRU9qnUuzgrQ4GT2KNV9vBcE5qE3t g59oZBxx292g3kBmVAC8V8eeIwlYHHfg7cw2+jCYz5LZpbNAqsxsMM7HZ0XoCbEIqj01 FQ== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 35phm1m6mp-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 01 Jan 2021 22:57:52 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 101Mkj0T056891; Fri, 1 Jan 2021 22:55:52 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 35perqa2yq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 01 Jan 2021 22:55:52 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 101MtohQ024250; Fri, 1 Jan 2021 22:55:51 GMT In-Reply-To: <87k0sw1f9q.fsf@logand.com> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5095.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9851 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 mlxlogscore=999 mlxscore=0 malwarescore=0 bulkscore=0 phishscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101010145 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9851 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 mlxscore=0 mlxlogscore=999 adultscore=0 bulkscore=0 malwarescore=0 spamscore=0 impostorscore=0 phishscore=0 clxscore=1015 lowpriorityscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101010146 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:262270 Archived-At: > > If we're defining predicates to check whether the length of a list is > > <, =3D, or > some value, those predicates should do something useful, o= r > > at least something one might expect, for non-proper lists as well, no? >=20 > What exactly means "something one might expect"? >=20 > I expect the predicates to work on proper list and > it should count the number of cons cells in the list. >=20 > I do not expect the predicates to count the last cdr differently > depending on its value. The question iss not what the behavior should be for proper lists. The question is what it should be for dotted lists (and circular lists). What is your reasonable expectation for dotted lists? I'd suggest these are two reasonable expectations for a dotted-list length comparison against a number: 1. Always raise an error. 2. Never raise an error. For #2, one reasonable expectation is, I think, that the value returned always be true or false, and exactly mirror the case for a proper list whose last element is the last cdr of the dotted list. That has a good deal of consistency. Non-nil cdrs are simply counted (irrespective of their non-nil values). Nothing more happens. (And the same can be said for a proper list: the non-nil cdrs are counted - nothing more.) "List" includes both proper and dotted lists. Because a list can have a non-nil last cdr, it's non-nil cdrs that I'd expect should be counted, not cons cells. But that's me. To me, that behavior for dotted lists would at least be of some _use_. Always raising an error for a dotted list is less useful. But even if for some reason (what reason?) you think #2 is _more_ useful, we don't even have #2. The question really is, What behavior do you want for a dotted list? So far, the behavior is to sometimes (1) raise an error and sometimes (2) return a true or false value. And there's little rhyme or reason for when it does one or the other. These use my Lisp definitions, which I guess do what the current C code does for dotted lists: (length> '(1 . 2) -1) ; true (length> '(1 . 2) 0) ; true (length> '(1 . 2) 1) ; true (length> '(1 . 2) 2) ; ---ERROR--- (length> '(1 . 2) 42) ; ---ERROR--- (length< '(1 . 2) -1) ; false (length< '(1 . 2) 0) ; false (length< '(1 . 2) 1) ; false (length< '(1 . 2) 2) ; false (length< '(1 . 2) 24) ; ---ERROR--- (length=3D '(1 . 2) -1) ; false (length=3D '(1 . 2) 0) ; false (length=3D '(1 . 2) 1) ; false (length=3D '(1 . 2) 2) ; ---ERROR--- (length=3D '(1 . 2) 42) ; ---ERROR--- Is that really what you expect/want? Not I. I prefer that those ERROR cases return false for >, and true for =3D and <. Which is what I implemented.