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.help Subject: RE: How to avoid compiler warning `unused lexical variable' for `dolist' or `dotimes'? Date: Fri, 8 Jan 2021 09:22:51 -0800 (PST) Message-ID: References: <7eec4142-3c37-4084-9ea1-73df5df2c821@default> 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="3930"; mail-complaints-to="usenet@ciao.gmane.io" To: Stefan Monnier , help-gnu-emacs@gnu.org Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jan 08 18:23:54 2021 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 1kxvUQ-0000vF-Ag for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 08 Jan 2021 18:23:54 +0100 Original-Received: from localhost ([::1]:34754 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kxvUP-0006WX-CC for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 08 Jan 2021 12:23:53 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58162) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxvTb-0005lb-NV for help-gnu-emacs@gnu.org; Fri, 08 Jan 2021 12:23:03 -0500 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:39854) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kxvTZ-0000zv-6C for help-gnu-emacs@gnu.org; Fri, 08 Jan 2021 12:23:03 -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 108HJBcK020643; Fri, 8 Jan 2021 17:22:54 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=wSG51CnTWw9WvtPKLapQFUgnWf5KS3azuzrUpWIQifM=; b=0dbp384GAAuVNfuCJbvd522R3dgGd+ku0ZSZLQxrHf5D8lH1potHsHKMjrIiWevKZ5sa 1ZmjCqNbfT5DJhdQ2k4wrQlzJgfvTpvmtjloqL11icUlCxnJqk/9+4a0KHgq854ty0T4 ALgglpy8tCrjgCaYogDqDIkxPJKqt7wm8TkvklsXdYXvWwIGLl2rlR12kEOoqh3jSN/4 FnsNCvxpUGe1pkBChNCS2sPhl1nGZP0bLmbYFBmtMMMUNshaGHy4GG6sCBKudEeQ+0Ff n6i1y3FO8L2JqKnMKQN0TKDuizuh0QFZK+ByNTGmQc5SFeAnUdaQXTZaD4w7CrR4nVp/ tg== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 35wepmj3dq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 08 Jan 2021 17:22:54 +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 108HKkVw162968; Fri, 8 Jan 2021 17:22:53 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 35w3qvq39j-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 08 Jan 2021 17:22:53 +0000 Original-Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 108HMqmo004384; Fri, 8 Jan 2021 17:22:52 GMT In-Reply-To: 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=9858 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 malwarescore=0 mlxscore=0 spamscore=0 mlxlogscore=999 phishscore=0 bulkscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101080095 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9858 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 bulkscore=0 spamscore=0 impostorscore=0 phishscore=0 lowpriorityscore=0 suspectscore=0 priorityscore=1501 mlxscore=0 malwarescore=0 clxscore=1015 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101080095 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-Spam_score_int: -46 X-Spam_score: -4.7 X-Spam_bar: ---- X-Spam_report: (-4.7 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.247, 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: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.help:127111 Archived-At: > FWIW, I remember that I used to like `do*` back when I was programming > in Common Lisp, but nowadays I find it rather inscrutable. I agree with your last phrase, and I was never a fan of `do*'. > In that category I think Scheme's named let is infinitely superior: both > more general and easier to understand. Too bad that it's kind of a pain > to implement efficiently in ELisp, but Vincent's `recur-let` gives > a pretty good approximation (still more general and easier to understand > than `do*`). > (c.f. > https://urldefense.com/v3/__https://github.com/VincentToups/recur__;!!Gqi= vPVa > 7Brio!LHaFHC2fIL6O-KnVleahtiHtmmkLRwamJMjoe9mglmjt2ncWgr0mSNs9uMVnhdAd$ )= . Sure. It can be useful to move recursion to iteration under the covers, or even above the covers through the idiom of using an accumulator. Elisp has a long way to go, in terms of doing such things under the covers. Put differently, doing such things is not something new in software engineering. I guess Elisp hasn't had the necessary itch-scratchers or the felt need. For much (most?) user use of Elisp, performance isn't particularly important. The story is different for other Lisps, like Common Lisp, which have more general use. > > There's nothing particularly odd, new, or unlispy > > about such design. It's very old in Lisp iteration. >=20 > Old doesn't mean good. Right. Nor does new. Or young. There's still room for Elisp to learn from Common Lisp (and, as you point out, from elsewhere).