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

On 21/04/2025 23:16, Kaz Kylheku wrote:

On 2025-04-21, bart <bc@freeuk.com> wrote:

I don't now think think there is any argument that will make any
difference. People here genuinely think that writing:
>
    for (ch = 0; ch <= 255; ++ch)
>
is far superior to this 'primitive' version:
>
    do ch = 0, 255

 Obviously, the former is more primitive, because the second can
be made out of the first with a preprocessor, whereas the converse
is not true. If A can be made out of B, but B not out of A,
B is more primitive.
 The former is undeniably more verbose for the uses provided by the
second.
 It is also much more flexible.
 Thanks to the macro preprocessor, it can almost express the second form,
just with more punctuation:
    for_range (ch, 0, 255)
 If a built-in "do" range loop existed in C, it would likely have
the parentheses.
 

No amount of discussion or arguments will make them change their minds.

 Mostly, you are projecting onto people opinions they don't actually
have.

Read the thread. Nobody has changed their opinion on C for-loops, or agreed with its various problems, or thought that a streamlined loop would be a welcome.
(Only Keith cautiously welcome the idea of such a feature, while MS said he would vote against it, and JP said they would have proposed it on April 1st.)

 You're also not a fan of unbridled language extension, based on your
past opinions about, oh, C++ and whatnot.

I don't agree with language-building features. You just end up with a monstrosity like C++.

Your primary reaction to some new idea is to reject it as complex
fluff that you'd rather not undertand.
 How brushed up are you in using C17 or C23?

C23 is nothing particularly interesting. A few features I wont't be able to rely on until I'm dead.

You've also expressed oppositions to extending C, because
development of C makes it a moving target for your projects.

As I said, development of is not that interesting. Basically sticking plaster fixes.
 > Of course people are going to push back on the idea of making new> statements, if they can be decently obtained or simulated using

preprocessing.
 Would you support an "unless" statement being added to C, given
that we can just:
 #define unless(x) if(!(x))
 Or, unless which does not take else:
 #define unless(x) if (x) { } else
 Adding a new statement to C is a big deal, compared to someone
adding a macro to their code.

You can't /just/ add such a macro. To be useful, it has to be standardised. And then, you'd probably need #include <stdunless.h> to use it.

Literally the first question about any proposal for a new language
feature is going to be: can obtain that, or substantially obtain it
using existing features

I think C's macros are the main thing that have hindered its development.
Why add a new core feature, when some tacky, half-assed macro can be used? Or, sometimes, a typedef.
At one time, every other app I looked at defined its own ARRAYLEN macro, or MIN/MAX, or STREQ.
There is no need to add a formal lengthof() operator when every user can create their own variation of ARRAYLEN in a few seconds.
Result: most people still end up writing sizeof(myarray)/sizeof(myarray[0]). In the meantime, I'm been able to write myarray.len for 43 years, and also:
    print a, b       # who cares about format codes
As for MIN/MAX, I routinely use:
    max(a, b)
    max(x, y)        # overloaded per type
    a max:=b         # augmented assignment
    a.max            # maximum value of a's type
    T.max            # maximum value of type T
Oh, and I already have Unless:
    unless a then b end
    return 0 unless cond
It is not a macro.