Re: unwind-protect within while-no-input

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 08 May 2024 15:28:38 -0400
> 
> >> How does my-function run the unwind-forms when it is interrupted by
> >> while-no-input?
> >
> > How can a function cause its caller to do anything at all?  It can't.
> > If the caller wants to make sure some unwind-forms will always run
> > after my-function either returns locally or exits non-locally, the
> > caller needs to arrange for that.
> 
> I don't want to run the unwind forms "after" my-function returns or
> exits.  I want them to run wherever they are inside my-function, just
> like a normal unwind-protect.
> 
> Let me try to explain again what I want: I want a completely normal
> unwind-protect, exactly how unwind-protect works normally:
> 
>   (unwind-protect BODYFORM UNWINDFORMS...)
>   
>   Do BODYFORM, protecting with UNWINDFORMS.
>   If BODYFORM completes normally, its value is returned
>   after executing the UNWINDFORMS.
>   If BODYFORM exits nonlocally, the UNWINDFORMS are executed anyway.
> 
> Except that I want the UNWINDFORMS to not be interrupted by a
> *surrounding* while-no-input or quit or any other kind of nonlocal exit.
> 
> Is there any way to do that?  ("Move the while-no-input inside the
> unwind-protect" is not an answer, because then it's not a *surrounding*
> while-no-input anymore)

IMO, you are trying to solve a problem that is impossible to solve in
general: a function cannot be responsible for the environment in which
it is called.  You keep talking about while-no-input, but that's just
an example; there's a virtually infinite number of ways the caller of
your function can call it in a way that thwarts any attempt of yours
to prevent non-local exits.  Given enough motivation and effort (and
reliance on the internal implementation details), you could perhaps
fix that single case of calling the function inside while-no-input,
but that will not solve all the rest.

The correct solution to these problems is to document the requirements
of your function from the callers, and let the callers deal with that
according to their needs.  (I suspect that in the case that bothers
you, you yourself are that caller, which makes it easier to implement
such protocols.)

Btw, you never explained why you are bothered specifically by
while-no-input.  Nor did you describe the problem.  Instead, you
describe a solution ("I want a completely normal unwind-protect..."),
and ask us to program such a solution for you without understanding
the problem or the reason why you want to solve it with a "normal
unwind-protect".  That is a sure way of making this discussion very
frustrating, if not downright useless.  Look how many messages this
thread has already amassed, and how many solutions were proposed, only
to be rejected by you for some reason that was never stated before.