From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Tomas Hlavaty Newsgroups: gmane.emacs.devel Subject: Re: Internationalize Emacs's messages (swahili) Date: Sun, 27 Dec 2020 18:33:44 +0100 Message-ID: <87y2hjqhl3.fsf@logand.com> References: <87o8ivumn5.fsf@telefonica.net> <83sg7xrgr5.fsf@gnu.org> <83h7odrdwy.fsf@gnu.org> <86sg7w39fh.fsf@163.com> <83pn30pku5.fsf@gnu.org> <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> <87pn2wstw1.fsf@logand.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23914"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, larsi@gnus.org, emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 27 18:34:35 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 1ktZwB-00065W-Je for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 18:34:35 +0100 Original-Received: from localhost ([::1]:54168 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktZwA-0004SK-Mq for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 12:34:34 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50344) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktZvc-00040U-PL for emacs-devel@gnu.org; Sun, 27 Dec 2020 12:34:00 -0500 Original-Received: from logand.com ([37.48.87.44]:54658) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktZva-0007KM-Sr; Sun, 27 Dec 2020 12:34:00 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id 4CA0D19F636; Sun, 27 Dec 2020 18:33:47 +0100 (CET) X-Mailer: emacs 26.3 (via feedmail 11-beta-1 I) In-Reply-To: Received-SPF: pass client-ip=37.48.87.44; envelope-from=tom@logand.com; helo=logand.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, 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:261910 Archived-At: On Sun 27 Dec 2020 at 00:38, Richard Stallman wrote: > > What about length= length/= length< length<= length> length>= > > predicates? > > One of the basic design guides of Emacs Lisp is rejection of > the idea of adding more functions in the name of symmetry. Interesting. Where can I read about the "basic design guides of Emacs Lisp"? I looked at "(elisp) Programming Tips" but did not find anything. rgrep on the emacs repository shows some counter-examples, i.e. stuff added in the name of symmetry. It is not clear, what exactly "the idea of adding more functions in the name of symmetry" means. Elisp has = /= < > <= >= predicates. Does it mean that <= /= > >= are against that idea because they can be trivially expressed using = and < so programmers should write those "expansions" by hand all over the place? rgrep gives me the following hits: 216 "(not (=" 19 "(not (>" 12 "(not (<" 3 "(not (<=" 1 "(not (>=" 0 "(not (/=" Each usage of not makes the code harder to reason about. I personally prefer the following heuristic: - use < and <= rather than > and >= (read the predicate left to right from smaller to bigger values) - prefer when/unless/while/until and swap if branches to using /= or negation This way there is almost no need for /= > >=, except they are still needed for convenience when used in a different context, e.g. when passed as an arg to a function. > If there is a use for longer-than-p, or length> we could call it, > it may be worth adding that function, but let's skip the other 5 > if they are not actually needed. rgrep on the emacs repository gives me the following counts: 732 "(> (length" 703 "(= (length" 151 "(< (length" 71 "(>= (length" 66 "(<= (length" 46 "(/= (length" Using length in a predicate smells fischy. It is most likely a source of unnecessarily burned cpu cycles. It might be futile to train programmers to keep that in mind but it is relatively easy to find and fix. There are (+ 732 703 151 71 66 46) => 1769 potential cases in emacs. That's quite a lot of potential low hanging fruit for improvement. Defining all those predicates will allow to syntactically fix those places without touching anything else. Once those predicates are in place, we can be _sure_ that emacs is not uselessly counting length of lists in predicates. And those predicates could be further improved and optimized in the future without affecting the call sites. Now the questions is, how should such predicates look like. Ideally, they would look like = /= < > <= >= (accepting rest args) and numbers or lists where for lists lengths would be computed but short-circuited. But such generality might be overkill so I do not have an oppinion on that. Another issue already raised was: in C or elisp? If compiler-macros were an option, maybe that would give the most flexible and efficient implementation which would be easy to maintain. But I do not know much about such deep elisp details yet.