Re: Is this a bug in while-let or do I missunderstand it?

[Yuri Khan]

On Sat, 9 Nov 2024 at 01:44, 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.
    Evaluate each binding in turn, stopping if a binding value is nil.
    If all bindings are non-nil, eval BODY and repeat.

In your case, the sequence is:

1. Evaluate the expression ‘t’ in the first (and only) binding. This yields ‘t’.
2. Bind the result of step 1, ‘t’, to local variable ‘run’.
3. Check if ‘run’ is nil. It isn’t, so proceed to step 4.
4. There are no more bindings. Run the body.
4a. Evaluate ‘(message "Running")’.
4b. Evaluate ‘(setf run nil)’. This changes the value of ‘run’ to nil.
5. Repeat from step 1.

Re-evaluating every binding’s expression is expected. Consider this usage:

    (while-let ((values-to-process (get-values)))
      (while values-to-process
        (setq value (pop values-to-process))
        (process value)))

At the end of each outer loop’s iteration, ‘values-to-process’ is nil,
but you don’t want to break out of the outer loop immediately, you
want to check if there is more work to do.