From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Alfred M. Szmidt" Newsgroups: gmane.emacs.devel Subject: Re: Internationalize Emacs's messages (swahili) Date: Sun, 27 Dec 2020 18:34:17 -0500 Message-ID: References: <87o8ivumn5.fsf@telefonica.net> <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> <83blefkte2.fsf@gnu.org> <87h7o69aa8.fsf@gnus.org> <87pn2uq3ty.fsf@logand.com> <87ft3qq2kz.fsf@logand.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5840"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, emacs-devel@gnu.org, eliz@gnu.org, monnier@iro.umontreal.ca To: Tomas Hlavaty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 28 00:34:50 2020 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 1ktfYo-0001PY-7t for ged-emacs-devel@m.gmane-mx.org; Mon, 28 Dec 2020 00:34:50 +0100 Original-Received: from localhost ([::1]:59472 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktfYn-000876-8p for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 18:34:49 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:46630) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktfYJ-0007hH-7t for emacs-devel@gnu.org; Sun, 27 Dec 2020 18:34:19 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:58914) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktfYI-0005zl-U1; Sun, 27 Dec 2020 18:34:18 -0500 Original-Received: from ams by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1ktfYH-0002X5-Oi; Sun, 27 Dec 2020 18:34:17 -0500 In-Reply-To: <87ft3qq2kz.fsf@logand.com> (message from Tomas Hlavaty on Sun, 27 Dec 2020 23:57:48 +0100) 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:261950 Archived-At: > However, if somebody writes such code, it is almost trivial to fix > it with search and replace: > > "(= (length" -> "(length=" > "(< (length" -> "(length<" > "(> (length" -> "(length>" > "(/= (length" -> "(length/=" > "(<= (length" -> "(length<=" > "(>= (length" -> "(length>=" > > (plus extra closing paren) > > Users will assume that these length>= hacks will make their code > magically better, when they just hide a problematic form -- doing a > possibly complicated operation inside a predicate call. It will make their code better. I do not see any magic there, it is pretty simple and logical. I don't see how. The pretense here is optimization, the user has to be active no matter what even to discover these functions. The two functions are advertised as equal as well, so there is no possible way for the user to know which one to use when, and it might be suprising that the behaviour (in run time) is different. If the two forms are exactly equivalent, then the bytecompiler should be able to do the work instead of the user. And is it just me, but I'd expect that length>, etc takes two or more sequences and returns a boolean if one of sequence is larger/smaller/equal/...