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

On 22/04/2025 04:31, Kaz Kylheku wrote:

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

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

 Thus if C got, today, the loop features you advocate for, you wouldn't
use them; they would necessarily be after C23.

I don't actually write much raw C. When I generate C, especially if I want someone else to compile the code, then it needs to be conservative.
But most of my complaints have been do with other people's code. They're the ones that need to use those features!
In any case, for-loops account for 1% of what I find painful about C.

The time to lobby for them was 30-40 years ago, and in the right way.

I'm pretty sure I started complaining here 20 years ago! Perhaps more.

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.

 But that's exactly what some for loop from A to B would be, though.

Most of my replies haven't been about the feature itself: it's about people's attitudes to it, defending appalling coding styles, pretending the primitive C feature is superior to anything else, and generally refuting every point I try to make.
And when they run out of arguments, they start personal insults.

No; it just has to be defined at the top of a file which needs it.

Either it's in the language or it isn't. It is unacceptable to me to require headers for fundamental language features.

All of a sudden, something has to be in a document you can't be
bothered to read in order to be useful?

Do you think I haven't played around with such macros? Here's some from 2014:
#define PUTS puts
#define PRINTF printf
#define TO(i,x) for (i=x; i; --i)
#define FOR(i,a,b) for (i=a; i<=b; ++i)
#define FORD(i,a,b) for (i=a; i>=b; --i)
#define UPB(a) (sizeof(a)/sizeof(a[0]))
#define UPB0(a) (sizeof(a)/sizeof(a[0])-1)
#define LEN(a) (sizeof(a)/sizeof(a[0]))
But if writing a code fragment to post in a forum, for example, you can't use any of this stuff. People arren't going to download some separate header for these macros, and I don't want them plastered all over my example. It would also be silly ate to use that FOR macro for that /one/ for-loop in my code.
This stuff does need to be standardised to be useful.

Your own stuff is not standardized; presumably you worked on
it because you find it useful.

It is standardised in that no basic language feature, no standard library function, needs some declaration to be used. Example:
   proc main =
        puts("hello"
   end
In C that would need '#include <stdio>'. Here, 'puts' is defined in a file which is part of my standard library which is automatically included by default.

I think C's macros are the main thing that have hindered its development.

 C macros definitely hinder all kinds of tooling.

Just C syntax does that by itself! My editor uses Ctrl-PageUp/Down to step between functions. But it doesn't work for C source code: you need half a C compiler to figure out where each function starts.

Result: most people still end up writing
sizeof(myarray)/sizeof(myarray[0]).

 This leads to a bug when myarray is actually a pointer.
 GCC has a warning for sizeof ptr / sizeof ptr[0] specifically
to catch bugs in this idiom.
 It's pretty gross. To my understanding there is some initiative
to get some array length operator.
 Of course, you will never use it.

After nearly 50 years of using alternative languages? Probably not. By the time it became standard, I'd be dead.

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

 Not only you, but countless term projects in undergraduate compiler
class. So what?

Well, exactly. So how come we ended up with C as the world's primary systems language? Why hasn't C long acquired such useful core features?
However those undergraduates probably moved on to use a mainstream language, while I've successfully used mine to do 99% of my coding over decades.
(Actually, I've looked at countless amateur language projects over on Reddit. Most of them would be hopeless as systems languages. And half of them look like C!)