In this discussion, I shudder to mention that people often simply use all kinds
of additional logic to get a result. How much code have you seen that has some
variable like "completed = False" that can be set to True in multiple places
and many areas inside the loop are enclosed in an IF statement that only
executes when completed remains False. So there is one clean exit in the sense
that even when only half a loop has been done, it continues to the end of the
loop and leaves before the next iteration. True, there is no break or return
from the middle of the loop but logically there is if not for the convoluted
code to avoid it.
Similarly, can most "while" loops that you want to be "until" loops not be made
with a bit of code? I mean set first_time to True before starting. Set your
while condition to while first_time OR condition or some other such logic. That
guarantees you go into the loop even when condition is False. Within the loop,
negate first_time.
Does that look more like a simulated repeat until, with extra overhead?
As I see it, there are many viewpoints here. From a programming perspective, it
is nice to be able to state the overall shape of what you are doing in an
upfront-way and also something others can read. Some things like the C-style
for loop provide a bit of this but in a way I think outsiders may stare at as
in for (initialize; compare-condition; iterate-change) { ... }
That is sort of compact but I have seen it get quite complex. If designed for
readers, it might be designed a bit like what we do with keywords in functions
headers where you might specify the "names" of each such section to make it
clearer, and not just positional.
But some forms of loops like do {...} until ...
Make you have to scan forward to see what makes them end. That is not
necessarily bad as you may need to read the code to see how it sets up the
variables controlling the exit condition.
But if you want a wide open setup, where the conditions for the loop being
entered can be specified, then the condition for it to be repeated (if
different) can be specified and the condition at the end that makes you exit
without trying the condition on top, you can go nuts. As mentioned, some
languages have else clauses or finally clauses and error handling with things
like try() or some kind of on.exit() can cause weird things. Some languages may
even want you to be able to test some condition automatically after every
single statement and exit immediately.
Even if you disagree with the idea of picking a few constructs that are
commonly used or encouraged, you may want to consider what happens when you
make a language so bloated that compiling or interpreting it becomes a big
challenge and it has too many keywords.
When it comes to other perspectives like having algorithms able to evaluate a
program and prove it has no bugs, you may end up with a very restricted
programming language and still fail. Throw in the reality that your loop may
use variable manipulated in parallel by other threads and that your thread may
be killed as it runs and I wonder.
-----Original Message-----
From: Python-list <python-list-bounces+avigross=verizon....@python.org> On
Behalf Of Greg Ewing
Sent: Friday, September 10, 2021 2:40 AM
To: python-list@python.org
Subject: Re: Friday Finking: Contorted loops
On 10/09/21 11:47 am, Terry Reedy wrote:
> 2. It is rare useful. For loops are common. While loops are
> occasional (nearly an order of magnitude less common than for loops.
> Fractional loop constructs are rare.
I would say that fractional loops are more common than loops which truly need
to execute completely at least once, and aren't bugs waiting to be triggered by
an edge case such as empty input.
I seem to remember someone - maybe Wirth? - long ago expressing the opinion
that repeat-until loops often tended to be error prone, but I can't provide a
reference, sorry.
--
Greg
--
https://mail.python.org/mailman/listinfo/python-list
--
https://mail.python.org/mailman/listinfo/python-list
