unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: arthur miller <arthur.miller@live.com>
To: Yuri Khan <yuri.v.khan@gmail.com>
Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: Sv: Is this a bug in while-let or do I missunderstand it?
Date: Sat, 9 Nov 2024 13:38:24 +0000	[thread overview]
Message-ID: <DU2PR02MB10109F4094C90A796CD77B809965E2@DU2PR02MB10109.eurprd02.prod.outlook.com> (raw)
In-Reply-To: <CAP_d_8Wnx_Ed-4FvNax2PpcipSCr5HyAcf9N_e1nZu=xhLDhOg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]

>> >> (progn
>> >>   (while-let ((run t))
>> >>     (message "Running")
>> >>     (setf run nil))
>> >>   (message "out of loop"))
>> >>
>> >> It ends in infinite recursion. setf/setq have no effect on the lexical variable.
>> >
>> >Probably not infinite recursion but infinite loop.
>> >
>> >Why would you expect anything else? ‘while-let’ is documented as:
>> >
>> >    Bind variables according to SPEC and conditionally evaluate BODY.
>>
>> What should I expect?
>>
>> It does not says *read-only bindings*, it says bindings. Is it
>> unreasonable to store a value in an established lexical binding?
>
>I expect the binding is writable *but* it gets re-assigned on each iteration.

Yes.

>> That is what I expect while-let to be equivalent to.
>
>This is what I expect:
>
>    (progn
>      (let ((run))
>        (while (setf run t)
>          (message "running")
>          (setf run nil)       ; useless because ‘run’ will be
>reassigned right next
>        )
>      (message "not running")  ; unreachable
>    )
>

Mnjah; more like this:

(catch 'done
  (while t
    (let* ((run nil))
      (if run
          (do-body)
          (throw 'done nil)))))

I have already posted the macro expansions in respone to Phillip.
It is quite clear what is going on. I think it is a bug, or at
least very unintuitive behaviour. But the worst, we can see that the
claimed optimizaiton does not take place at all:

(pp (macroexpand-all
     '(while-let ((run t)
                  (x 'expensive)
                  (y 'more-expensive)
                  (z 'the-most-expensive))
        (message "running")
        (setf run nil))))

(catch 'done1522
  (while t
    (let*
        ((run (and t t)) (x (and run 'expensive)) (y (and x 'more-expensive))
         (z (and y 'the-most-expensive)))
      (if z (progn (message "running") (setq run nil)) (throw 'done1522 nil)))))

Which makes wonder if the convoluted code in subr.el is worth compared to the
naive implementation I posted. Perhaps someone can pull off the optimization with
 some clever macro, I don't know.

I think it was enough from me as an outsider to point out the possible bug. Whether
 people here wants to poop on it, or acknowledge and fix the bug is not up to me.

In other words, I think I am done here.

/best regards
________________________________
Från: Yuri Khan <yuri.v.khan@gmail.com>
Skickat: den 9 november 2024 14:15
Till: arthur miller <arthur.miller@live.com>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Is this a bug in while-let or do I missunderstand it?

On Sat, 9 Nov 2024 at 20:03, arthur miller <arthur.miller@live.com> wrote:
>
> >> (progn
> >>   (while-let ((run t))
> >>     (message "Running")
> >>     (setf run nil))
> >>   (message "out of loop"))
> >>
> >> It ends in infinite recursion. setf/setq have no effect on the lexical variable.
> >
> >Probably not infinite recursion but infinite loop.
> >
> >Why would you expect anything else? ‘while-let’ is documented as:
> >
> >    Bind variables according to SPEC and conditionally evaluate BODY.
>
> What should I expect?
>
> It does not says *read-only bindings*, it says bindings. Is it
> unreasonable to store a value in an established lexical binding?

I expect the binding is writable *but* it gets re-assigned on each iteration.

> (progn
>   (let ((run t))
>     (while run
>       (message "running")
>       (setf run nil))
>     (message "not running")))
>
> That is what I expect while-let to be equivalent to.

This is what I expect:

    (progn
      (let ((run))
        (while (setf run t)
          (message "running")
          (setf run nil)       ; useless because ‘run’ will be
reassigned right next
        )
      (message "not running")  ; unreachable
    )

[-- Attachment #2: Type: text/html, Size: 14580 bytes --]

  reply	other threads:[~2024-11-09 13:38 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-08 16:25 Is this a bug in while-let or do I missunderstand it? arthur miller
2024-11-08 19:23 ` Philip Kaludercic
2024-11-09  3:30   ` Sv: " arthur miller
2024-11-09  9:29 ` Yuri Khan
2024-11-09 13:03   ` Sv: " arthur miller
2024-11-09 13:15     ` Yuri Khan
2024-11-09 13:38       ` arthur miller [this message]
2024-11-09 13:41         ` Yuri Khan
2024-11-09 13:47           ` Sv: " arthur miller
2024-11-09 14:04             ` Yuri Khan
2024-11-09 14:44               ` Sv: " arthur miller
2024-11-09 16:33               ` Alfred M. Szmidt
2024-11-09 16:44                 ` Eli Zaretskii
2024-11-09 16:53                   ` Eli Zaretskii
2024-11-09 17:33                   ` Andreas Schwab
2024-11-09 18:07                   ` [External] : " Drew Adams
2024-11-09 18:18                     ` Alfred M. Szmidt
2024-11-09 20:02                       ` Jens Schmidt
2024-11-09 20:38                         ` Alfred M. Szmidt
2024-11-09 21:18                           ` Joost Kremers
2024-11-10 11:44                         ` Alfred M. Szmidt
2024-11-10 12:24                           ` Better documentation for non-binding clauses of if-let and friends Jens Schmidt
2024-11-10 14:51                             ` Sean Whitton
2024-11-10 16:58                               ` Jens Schmidt
2024-11-11 10:03                               ` Alfred M. Szmidt
2024-11-11  8:20                             ` Alfred M. Szmidt
2024-11-09 19:32                     ` Sv: [External] : Re: Is this a bug in while-let or do I missunderstand it? arthur miller
2024-11-09 22:36                       ` Drew Adams
2024-11-09 22:53                         ` Drew Adams
2024-11-14 21:50                   ` John ff
2024-11-09 20:29                 ` Sv: " arthur miller
2024-11-10  6:22                   ` Eli Zaretskii
2024-11-10 10:40                     ` Joost Kremers
2024-11-10 12:10                       ` Alfred M. Szmidt
2024-11-10 19:49                         ` Sv: " arthur miller
2024-11-10 18:18                     ` arthur miller
2024-11-11  5:13                       ` Yuri Khan
2024-11-11  8:49                         ` Sv: " arthur miller
2024-11-11 12:23                           ` tomas
2024-11-11 22:41                     ` Joost Kremers
2024-11-12 12:19                       ` Eli Zaretskii
2024-11-12 12:45                         ` Joost Kremers
2024-11-12 14:34                           ` Eli Zaretskii
2024-11-12 15:32                             ` Joost Kremers
2024-11-12 23:45                         ` Joost Kremers
2024-11-13  9:45                           ` Sean Whitton
2024-11-13  9:56                             ` Sean Whitton
2024-11-13 11:00                               ` Joost Kremers
2024-11-13 12:17                                 ` Sean Whitton
2024-11-14  7:55                                 ` Eli Zaretskii
2024-11-14  8:21                                   ` Joost Kremers
2024-11-14 21:51                               ` John ff
2024-11-14 21:52                                 ` John ff
2024-11-09 21:47             ` Sv: " Joost Kremers
2024-11-09 22:07               ` Sv: " arthur miller
2024-11-10  6:07               ` Andreas Schwab
  -- strict thread matches above, loose matches on Subject: below --
2024-11-12  3:36 arthur miller
2024-11-12  8:30 ` Joost Kremers
2024-11-12 17:55   ` Alfred M. Szmidt
2024-11-12 23:21     ` Sv: " arthur miller
2024-11-12 23:31       ` Joost Kremers
2024-11-12 23:08   ` arthur miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=DU2PR02MB10109F4094C90A796CD77B809965E2@DU2PR02MB10109.eurprd02.prod.outlook.com \
    --to=arthur.miller@live.com \
    --cc=emacs-devel@gnu.org \
    --cc=yuri.v.khan@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).