Friday Finking: Contorted loops

Avi Gross avigross at verizon.net
Fri Sep 10 17:36:22 EDT 2021


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.net at python.org> On Behalf Of Greg Ewing
Sent: Friday, September 10, 2021 2:40 AM
To: python-list at 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



More information about the Python-list mailing list