GNU bug report logs -
#63588
29.x: dotimes (possible) problem
Previous Next
Reported by: balducci <at> dschgrazlin2.units.it
Date: Fri, 19 May 2023 15:22:02 UTC
Severity: normal
Merged with 63586
Fixed in version 29.1
Done: Stefan Kangas <stefankangas <at> gmail.com>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 63588 in the body.
You can then email your comments to 63588 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#63588
; Package
emacs
.
(Fri, 19 May 2023 15:22:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
balducci <at> dschgrazlin2.units.it
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Fri, 19 May 2023 15:22:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
hello
the dotimes macro behaves differently in 29.x with respect to previous
versions
Basically: changing the value of the loop variable in the body of
dotimes does not seem to have any effect, where for versions <29.x it
used to.
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
The ability to jump out of the loop by pushing the loop variable over
the upper limit is something that I happen to use in my scripts, so
29.x breaks them somehow
Of course, there are very many other equivalent ways to
accomplish the same result, but I don't see why this one
shouldn't be supported (any longer)
Is the changed behavior intentional? Am I missing some blatant point here?
AFAICS, changing the value of the loop variable from inside the loop
body is supported by any other language which I know about
thank you very much in advance for any hint/feedback
ciao
-gabriele
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#63588
; Package
emacs
.
(Fri, 19 May 2023 15:43:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 63588 <at> debbugs.gnu.org (full text, mbox):
> changing the value of the loop variable in the body of
> dotimes does not seem to have any effect, where for versions <29.x it
> used to.
...
> The ability to jump out of the loop by pushing the loop variable over
> the upper limit is something that I happen to use in my scripts, so
> 29.x breaks them somehow
>
> Of course, there are very many other equivalent ways to
> accomplish the same result, but I don't see why this one
> shouldn't be supported (any longer)
>
> Is the changed behavior intentional? Am I missing some blatant point here?
>
> AFAICS, changing the value of the loop variable from inside the loop
> body is supported by any other language which I know about
No, it's not.
From CLTL2 [*]:
"Altering the value of var in the body of the loop
(by using setq, for example) will have unpredictable,
possibly implementation-dependent results. A Common
Lisp compiler may choose to issue a warning if such
a variable appears in a setq."
That allows an implementation of CL to define some
particular behavior in this regard. But it also says
that if it does, and if your CL code depends on that
behavior, then it won't necessarily be portable to
other CL implementations.
It's unfortunate that if this Elisp change isn't
backward compatible. That's indeed a consideration.
But it's wise for your code not to depend on being
able to change the loop variable and get any
meaningful resulting behavior.
Both in CL and Elisp `dotimes' lets you use RETURN
to break out of the loop. That should speak to one
of your use cases, at least.
(dotimes (ii 100 "*********")
(when (= 4 ii) (return "4444444444")))
CLTL2 says this:
"An explicit return statement may be used to
terminate the loop and return a specified value."
But I don't see where this is documented for Elisp.
Maybe it is documented somewhere. Should be.
___
[*] https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node89.html
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#63588
; Package
emacs
.
(Fri, 19 May 2023 16:08:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 63588 <at> debbugs.gnu.org (full text, mbox):
merge 63588 63586
thanks
> From: balducci <at> dschgrazlin2.units.it
> Date: Fri, 19 May 2023 10:54:46 +0200
>
> hello
>
> the dotimes macro behaves differently in 29.x with respect to previous
> versions
This is an exact duplicate of bug#63586 which you submitted recently.
Merged 63586 63588.
Request was from
Eli Zaretskii <eliz <at> gnu.org>
to
control <at> debbugs.gnu.org
.
(Fri, 19 May 2023 16:08:02 GMT)
Full text and
rfc822 format available.
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Wed, 06 Sep 2023 20:11:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
balducci <at> dschgrazlin2.units.it
:
bug acknowledged by developer.
(Wed, 06 Sep 2023 20:11:02 GMT)
Full text and
rfc822 format available.
Message #18 received at 63588-done <at> debbugs.gnu.org (full text, mbox):
Version: 29.1
Mattias EngdegÄrd <mattiase <at> acm.org> writes:
> 19 maj 2023 kl. 19.47 skrev Eli Zaretskii <eliz <at> gnu.org>:
>
>> Feel free to suggest a NEWS entry, and thanks.
>
> There is now a NEWS entry in emacs-29. Do modify it as you like.
It seems like that was all that needed doing here, so I'm closing this.
Reply sent
to
Stefan Kangas <stefankangas <at> gmail.com>
:
You have taken responsibility.
(Wed, 06 Sep 2023 20:11:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
balducci <at> units.it
:
bug acknowledged by developer.
(Wed, 06 Sep 2023 20:11:03 GMT)
Full text and
rfc822 format available.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Thu, 05 Oct 2023 11:24:13 GMT)
Full text and
rfc822 format available.
This bug report was last modified 204 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.