From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#63586: 29.x: dotimes (possible) problem Date: Fri, 19 May 2023 13:29:14 -0400 Message-ID: References: <4450.1684509068@dschgrazlin2.units.it> <83ednctipe.fsf@gnu.org> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="40437"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , balducci@units.it, 63586@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri May 19 19:30:26 2023 Return-path: Envelope-to: geb-bug-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 1q03vq-000A97-HI for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 19 May 2023 19:30:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q03vY-0007Hq-9f; Fri, 19 May 2023 13:30:04 -0400 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 1q03vW-0007Gw-Rc for bug-gnu-emacs@gnu.org; Fri, 19 May 2023 13:30:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q03vW-0001Zz-JJ for bug-gnu-emacs@gnu.org; Fri, 19 May 2023 13:30:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q03vW-0006zp-Ep for bug-gnu-emacs@gnu.org; Fri, 19 May 2023 13:30:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 19 May 2023 17:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63586 X-GNU-PR-Package: emacs Original-Received: via spool by 63586-submit@debbugs.gnu.org id=B63586.168451736526820 (code B ref 63586); Fri, 19 May 2023 17:30:02 +0000 Original-Received: (at 63586) by debbugs.gnu.org; 19 May 2023 17:29:25 +0000 Original-Received: from localhost ([127.0.0.1]:57312 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q03uv-0006yV-7v for submit@debbugs.gnu.org; Fri, 19 May 2023 13:29:25 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48739) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q03us-0006yI-Fj for 63586@debbugs.gnu.org; Fri, 19 May 2023 13:29:22 -0400 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id D2F951000E7; Fri, 19 May 2023 13:29:16 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8687C1000BE; Fri, 19 May 2023 13:29:15 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1684517355; bh=vf/ezHWEaIG72sV5q0kcHmn5Qn9rkKLPZ76sQT33O9c=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Qb3h4mkP4izwX0Ucdm1fLhPZJ65uQKyHf3CqhExHenrvlZLBlNwU/FbrE4OAq4kMA 2CWutpb2/9njSBSl0m8FBI3tCpss90HzL10yc+WHKj0OtnK6mYp6mV2mUv+7Zy3NFP YCo6lHx450xOk+IZyUtnFTknjrQqpwJOr+s2pgqFQK6s3kmWX9ZKwBISjIa0DpzF0w xJv7L3KItlr920bo9MAE4tvegRSJJ0ck7+3Edxa6IKVJXDEi+K/u9cQTGxumudjW+i pkWLAjxbPNwiqPT2pAuLjIKILgpsXZpmZRT4fh5yHoYxrug6QpV//EKNejgV9bpy9X tRQH4nxwCNZCA== Original-Received: from alfajor (unknown [45.44.229.252]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 2138C12039B; Fri, 19 May 2023 13:29:15 -0400 (EDT) In-Reply-To: <83ednctipe.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 19 May 2023 19:00:13 +0300") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:262015 Archived-At: >> Basically: changing the value of the loop variable in the body of >> dotimes does not seem to have any effect, It does, but only within the current iteration, because the variable is local to the iteration (each iteration gets a fresh new variable). >> where for versions <29.x it used to. Indeed it was changed last year for dynamically scoped ELisp to align it with the semantics used in the lexically scoped ELisp dialect (and thus simplify the macro). >> Here is a minimal stretch of dummy code clarifying the problem I'm >> reporting. >> >> emacs-29.0.91 (or 29.0.90) >> ========================== >> >> (dotimes (ii 10) >> (insert (format "%2d " ii)) >> (when (= ii 4)(setq ii 11)) >> ) >> ==> 0 1 2 3 4 5 6 7 8 9 >> >> emacs-28.2 (or any version <29.x) >> ================================= >> >> (dotimes (ii 10) >> (insert (format "%2d " ii)) >> (when (= ii 4)(setq ii 11)) >> ) >> ==> 0 1 2 3 4 > > I can only reproduce the behavior you see in 28.2 in Emacs 26.3. All > the later versions, starting from 27.1, behave like Emacs 29 does. AFAIK what the OP describes is new in Emacs-29 (commit c6c9dfc8670f5698634a8d5853853056ff928974). But the change only affects code that has not activated `lexical-binding`: for `lexical-binding`, the behavior has been with us "forever" (i.e. since Emacs-24, when `lexical-binding` was introduced). >> AFAICS, changing the value of the loop variable from inside the loop >> body is supported by any other language which I know about It's definitely not supported by Common Lisp, which explicitly allows both our old implementation and our new implementation (i.e. code like yours may or may not work depending on the CL implementation). Several other languages (starting with Pascal :-) either disallow or discourage modifying the iteration variable(s) inside the loop body. But in any case, the question is not whether it's a good idea or not: it used to happen to work and now it doesn't work any more. Maybe we should mention the change in etc/NEWS? Stefan