From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.help Subject: Re: Advantage using mapc over dolist Date: Tue, 03 Dec 2024 18:29:06 -0500 Message-ID: References: <87zflevbwm.fsf@neko.mail-host-address-is-not-set> <87h67ku813.fsf@neko.mail-host-address-is-not-set> <87jzcg4i9b.fsf@neko.mail-host-address-is-not-set> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1789"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: help-gnu-emacs@gnu.org To: Tomas Hlavaty Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Wed Dec 04 00:29:52 2024 Return-path: Envelope-to: geh-help-gnu-emacs@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 1tIcL2-0000LG-D3 for geh-help-gnu-emacs@m.gmane-mx.org; Wed, 04 Dec 2024 00:29:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tIcKR-0001to-F9; Tue, 03 Dec 2024 18:29:15 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIcKP-0001tQ-OY for help-gnu-emacs@gnu.org; Tue, 03 Dec 2024 18:29:13 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tIcKN-0005B7-Ou for help-gnu-emacs@gnu.org; Tue, 03 Dec 2024 18:29:13 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id AC07B100043; Tue, 3 Dec 2024 18:29:08 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1733268547; bh=7kH1NuYQ5sj2IIIA+5SqJtyUbVG+NPjTkxV9LQ8dnBw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=RrKqPR86Gw8ZVNTOx+OpZAsZLfjq1W+BYHkg6AFGfD7NwhR0BVgQC/gAj9hGLbG3k tFlcvBDqmwzd/XIEAo3LtmH3ibcXbq18mruBRijqFI4q51jpNmU7lvU8O6NHIcpbln gNamIKgbTVc1iiSCexq2TdEk+iHv/KvlBL5dADhqZTgc9XGPbXI6W7GD9W9bp35pEb iM9I2y6rGf7ejK2XmDRLJlAhNMbUGF3SHLZKoXdUE4DtR0wW/Mpq9yB1kqZNsTetC+ anxOoFEO+E+DJVSkmKJdrnIY0HSsACu9QUBzn2SgS2jgNoLfFVtk4d5GfOdjEjEpys NLhIaaZK2iaYA== Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 7247E10002E; Tue, 3 Dec 2024 18:29:07 -0500 (EST) Original-Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5F49D12049E; Tue, 3 Dec 2024 18:29:07 -0500 (EST) In-Reply-To: <87jzcg4i9b.fsf@neko.mail-host-address-is-not-set> (Tomas Hlavaty's message of "Tue, 03 Dec 2024 21:35:28 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.help:148578 Archived-At: >> Richard was strongly opposed to the use of the CL package because of its >> "stepping" all over the ELisp namespace. For years, this manifested >> itself in the fact that use of CL within Emacs's own code was generally >> shunned and tolerated only with (eval-when-compile (require 'cl)), >> meaning that you could use CL only when it could be compiled away during >> byte-compilation (by macro-expansion and/or inlining). So you could use >> `ecase` but not `some`. > How did you decide what should be renamed to cl-*? Everything that was defined in the CL library. > Why was IF not renamed to cl-if? Because `if` was never defined in the CL library but in `eval.c` (and the byte-compiler). > Why do you think CASE is CL? Because it's defined in `cl-macs.el`, i.e. in the CL library (tho this file now belongs to the CL-Lib library). The renaming was motivated by very practical constraints, so there was very little opinion involved in which things were renamed and which weren't. "Very little" is not the same as "no opinion", admittedly. For example, I did refrain from renaming `setf` and instead re-implemented it outside of CL-Lib, integrating it into "core ELisp". Also, we later re-re-named things like `cl-caadr` to just `caadr` (i.e. integrating it into "core Elisp"). > How do you feel about code like this? > > (defun tempo-is-user-element (element) > "Try all the user-defined element handlers in `tempo-user-elements'." > ;; Sigh... I need (some list) > (catch 'found > (mapc (lambda (handler) > (let ((result (funcall handler element))) > (if result (throw 'found result)))) > tempo-user-elements) > (throw 'found nil))) > > Do you think duplicating SOME this way is better than embracing SOME? Personally, I think it should (require 'cl-lib) and then use `cl-some`. > In my code I just require cl-lib and add the cl- prefix where needed and > live with that. Same here. Stefan