Re: Loops (was Re: do { quit; } else { })

On 24.04.2025 14:25, David Brown wrote:

On 23/04/2025 19:43, bart wrote:

On 23/04/2025 16:31, David Brown wrote:

[...]
>
We are all going to have different first-glance opinions on different
bits of code.

>
What's your initial opinion of this 500-line example:
[...]

 
You missed the bit where I said I am not interested in examining bad
code.  Nor am I interested in Lisp, so I have no interest in looking at
that.

Right. (I see that bart still does this stupid argument trick.)

Here's one of the functions from it:

But I spent a *few seconds* to simply _reformat_ that code (in my
brain[*]) and it seems quite obvious!

[*] Below you find the brain dump codified for the post...

>
   lval rest(lval *h, lval *g) { lval *f = h-1; lval r = 0; for (;
f>=g; f--)
     r = cons(h, *f, r); return r; }

    lval rest (lval *h, lval *g)
    {
        lval r = 0;
        for (lval *f = h-1; f>=g; f--)
            r = cons(h, *f, r);
        return r;
    }

I just swapped the two [independent] assignments (r and f) so I got
the "complete" 'for' loop which is even of the simple type (the one
that also bart may understand), with just one running parameter 'f'.

They're obviously constructing in 'r' the return value by iterating
from the right to left. (The functional effect of course depends on
cons() that is undocumented here, but r=cons(..., r) is exposing.)

 
Presumably that makes sense to the people who wrote the code.  But it
makes no sense to me.

(It's obviously much simpler than it was in its unformatted state.)

That is /not/ because of some syntax or
formatting issue, or the missing clause in the "for" loop - it is
because I don't know the types, the functions (or macros) used, the
purpose of this function, the way memory and resource management is
handled in this code, the meaning of the single-letter identifiers, or
anything else about it.

And of course you're right.

 
How the code is formatted is a drop in the ocean in the effort needed to
understand the code, what it does, and where it fits with everything
else in the code base.
 

Here's what my visualisation tool produces:
>
     global function rest(ref i32 h, g)i64 =
         ref i32 f
         i32 r
>
         f := h-1
         r := 0
         while f >= g do
             r := cons(h,f^,r)
             f--
         od
         return r
     end

In my book this non-abstracted form is harder to understand than the
simple reformatted 'for' loop version. (and if we'd replace the 'while'
by a 'goto' based construct it would get yet more harder to identify
the semantic building blocks. (But it's pointless to discuss that with
you, bart; given your arguments yet I'm sure you don't grok that.)

Yes, you might apply a C formatter too, and keep it in C, it won't fix
that for-loop though.

Yes, the 'for' loop wasn't sensibly used for that algorithm. But it
was trivial to fix that. (And it's no argument against 'for', just an
argument against bad programmers and badly written code, as David also
said.)

 
The for-loop is basically irrelevant for understanding the code.
 
I fully agree that your "visualisation" here - or a re-factoring in C to
use a "while" loop rather than a "for" loop - makes the code easier to
read and makes it more obvious what the mechanics of the function are.

The (low-level) [imperative] _mechanics_ wasn't the crucial thing here
for understanding the code.

And if I were writing the same function myself, I'd use a while loop
rather than a for loop.

I wouldn't, as I demonstrated.

I'd guess you also wouldn't have used 'while' if you'd also have spent
the 5-10 seconds (that I had spent) to "analyze" the code beforehand.

So don't misunderstand me here - I am not a fan
of the way that function is written.  But I can't judge the format
without a lot more context, and such judgement would be highly
subjective.  And the formatting is a very minor aspect of understanding
the code.

Janis