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: lengths and stuff Date: Sat, 26 Dec 2020 21:23:10 -0800 (PST) Message-ID: References: <87o8ivumn5.fsf@telefonica.net>> > <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>> <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; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35552"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: Daniel Brooks Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 27 06:26:10 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 1ktOZF-00099A-QK for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 06:26:09 +0100 Original-Received: from localhost ([::1]:55492 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ktOZE-00037w-TW for ged-emacs-devel@m.gmane-mx.org; Sun, 27 Dec 2020 00:26:08 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55088) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktOYg-0002fV-92 for emacs-devel@gnu.org; Sun, 27 Dec 2020 00:25:34 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:40528) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ktOYc-0005Tz-E3; Sun, 27 Dec 2020 00:25:33 -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 0BR5PKkD060274; Sun, 27 Dec 2020 05:25:20 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=yy0xG5DUyp+/gZNZIOVj62nxh32M3uZAiStHDMggKOo=; b=uCApOzmuL39FZd+vC+t8pEXtVDA+3uxbQSdSbknPQQKQhVNP/PV/+o1k2PAMChXzsEC+ 8rJBMvXM27dh/xD69Q8Ch93S+pUtj/pAOWgP+RHdIDwktpooIL1kyN6ZpsnEVZI+5fOa Pyd/jLFhhF9rvgiUBgkt4WKZP1xnUIoF7NX5yPCC0TBsQ4Gw107gAHd7xvTj/OII5SNU nXcFNvGkTLpXrTLe1mUuIRf8Ro0DnebRRkbyddQVcrRavv9KPmMfJpJnasA1/uJo+gsw 8lJEGBYYh2wqq5xvkajvOdLIPf/g0+W9MYQGpb0hXymGpDWQK4LWWbObGflNEq0Gvv24 sQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 35phm183cj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 27 Dec 2020 05:25:20 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 0BR5FmT3076378; Sun, 27 Dec 2020 05:23:20 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userp3020.oracle.com with ESMTP id 35pexng0n7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 27 Dec 2020 05:23:19 +0000 Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 0BR5NBJD025309; Sun, 27 Dec 2020 05:23:11 GMT In-Reply-To: <87czyvsv3h.fsf_-_@db48x.net> 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=9846 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 adultscore=0 spamscore=0 malwarescore=0 mlxscore=0 mlxlogscore=999 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2012270033 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9846 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-2012270034 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:261881 Archived-At: > -----Original Message----- > From: Daniel Brooks > Sent: Saturday, December 26, 2020 8:59 PM > To: Drew Adams > Cc: Eli Zaretskii ; Stefan Monnier ; > larsi@gnus.org; emacs-devel@gnu.org > Subject: lengths and stuff >=20 > Drew Adams writes: >=20 > > With that "solution" you've only added a new problem: you > > now need to advertise the new functions and advise users > > to use them, not `length', in such a use case. Which > > means you still have the need to identify the relevant use > > cases, which means teach them about the `length' gotcha > > (or hope they follow advice without understanding). IOW, > > now you have 2 problems... >=20 > Users certainly do need to know the performance cost of the functions > that they use. But they also need alternatives. If (> (length list) n) > is a trap for new players, then document it as so _and_ mention that > there is a specific function that can be used to avoid the trap. But > it's also worth mentioning that maybe the code should use a vector > instead of a list, if the length is so important. I spoke to that (e.g. doc guidance) a bit already: https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg01757.html 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. Learning to `throw' out of a list traversal (or whatever) when you can tell it's time to quit is a _general_ solution/idiom - good to know about even if it's not always the most appropriate. That should be taught in the manuals (in this general don't-continue-needlessly context), even if many prefer things like `cl-loop'. There are no specific functions that can be used to avoid the trap. Not in general. Code that DTRT in any given context can be short, sweet, and clear. I see no help offered by `length<' & compagnie. 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.=20 > Also, as was pointed out, this very thing happens 735 times in the Emacs > lisp codebase. Probably most of those have no great performance impact, > but it's a good observation. 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. I wouldn't be in favor of systematically avoiding use of `length', as if all uses are poisonous. That would almost be akin to wrapping all uses of `dolist' in a `catch'. It sends human readers the wrong message. When it's important to avoid traversing more than necessary, make that clear. Avoiding it _always_ makes it less clear when it's actually needed, not more. (Just one opinion.)