Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Janis Papanagnou <janis_papanagnou+ng@hotmail.com>
Newsgroups: comp.lang.c
Subject: Re: Loops (was Re: do { quit; } else { })
Date: Thu, 24 Apr 2025 18:51:51 +0200
Organization: A noiseless patient Spider
Lines: 121
Message-ID: <vudq78$20dtl$1@dont-email.me>
References: <vspbjh$8dvd$1@dont-email.me> <vu01k7$1bfv2$1@dont-email.me>
 <vu0720$1dva7$1@dont-email.me> <vu2hmg$3jn88$1@dont-email.me>
 <vu2mkc$3noft$1@dont-email.me> <vu38da$735n$1@dont-email.me>
 <vu3j7s$g755$1@dont-email.me> <87ecxmv4t4.fsf@nosuchdomain.example.com>
 <vu401g$reom$1@dont-email.me> <20250420200823.908@kylheku.com>
 <vu5bqp$230jl$2@dont-email.me> <20250421113640.839@kylheku.com>
 <vu67up$2ubvr$1@dont-email.me> <20250421125957.29@kylheku.com>
 <vu6kkt$392e6$1@dont-email.me> <vu6q3b$3jhq1$1@paganini.bofh.team>
 <vu7r19$da0o$1@dont-email.me> <20250422103555.547@kylheku.com>
 <vu8sm8$18fhc$2@dont-email.me> <vub14h$3d9kt$1@dont-email.me>
 <vub8rh$3kfla$1@dont-email.me> <vudak2$1i7us$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 24 Apr 2025 18:51:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="df5710a58b15b349e429f31982af4b9d";
	logging-data="2111413"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/eDHNOcx8zTrvM2t9OIhqw"
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101
 Thunderbird/45.8.0
Cancel-Lock: sha1:vbu9IY779N6Pqei+mUAE4V05nHU=
In-Reply-To: <vudak2$1i7us$1@dont-email.me>
X-Enigmail-Draft-Status: N1110
Bytes: 5941

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