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: lengths and stuff Date: Sun, 27 Dec 2020 18:56:08 +0100 Message-ID: <87v9cnqgjr.fsf@logand.com> References: <87o8ivumn5.fsf@telefonica.net>> <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>> <87im8ob707.fsf@gnus.org>> <87eejcb6nx.fsf@gnus.org>> > <875z4ob5c9.fsf@gnus.org>> > <83mtxzly4f.fsf@gnu.org>> <87czyvsv3h.fsf_-_@db48x.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39049"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 27 18:57:04 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 1ktaHw-000A2N-9H for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 18:57:04 +0100 Original-Received: from localhost ([::1]:38700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktaHv-00036F-BN for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 12:57:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53650) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktaHB-0002fD-D0 for emacs-devel@gnu.org; Sun, 27 Dec 2020 12:56:17 -0500 Original-Received: from logand.com ([37.48.87.44]:59742) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktaH4-0001zY-Ub for emacs-devel@gnu.org; Sun, 27 Dec 2020 12:56:15 -0500 Original-Received: by logand.com (Postfix, from userid 1001) id B4E5319F638; Sun, 27 Dec 2020 18:56:09 +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:261911 Archived-At: On Sat 26 Dec 2020 at 21:23, Drew Adams wrote: > And as I said, `length' is not so special in this regard. `map', > `dolist', and others also provide the same rope to hang yourself with. length is different than map and dolist. length is about a property of a list, namely about number of items. map and dolist are about doing something with items of list. Using length in a predicate is yet completely different and most likely bad because to answer the predicate, traversing the whole list is wasted time and energy. > There are no specific functions that can be used to avoid > the trap. There are not, but there could be. > I see no help offered by `length<' & compagnie. The idea is that the intent is expressed in a way that can _guarantee_ that useless length computation is avoided. > And if the list in question is short, and the context is > not performance-critical (e.g. tight loop that's important), > then there may be no reason to bother about not traversing > it entirely. IOW, this stuff is best considered case by > case. Lisp already has all that's needed to create clear > code that does what one wants AND conveys to human readers > what's done and why. In theory. In reality, look at emacs code. The new predicates will allow not worrying about the trap and be sure that it is not there. And if somebody falls in the trap again, the new predicates will make it easy to fix, simply by search and replace. > If a given case has no performance impact, then it's > maybe better NOT to provide code that might give the > impression that we're trying to avoid a particular > performance penalty. Of course in middle cases, which > might not be obvious to a human reader, we may need to > make things clear explicitly. But how do you know if it has or has not performance impact unless you investigate each case? With the new predicates, you do not need to investigate each case because it will be taken care automatically. > I wouldn't be in favor of systematically avoiding use > of `length', as if all uses are poisonous. In fact, it kind of is, especially when used in a predicate. > That would almost be akin to wrapping all uses of `dolist' in a > `catch'. Why? That does not make sense.