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

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

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

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

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.

If a streamlined loop were added to C, you'd be among the last coders
to use it.

(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++.

But C++ is becoming more and more of a monstrosity specifically by
acquiring numerous features that /cannot/ be achieved with its existing
language-building features. (Sure, the language-building ones too,
on the library side.)

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.

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

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

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.

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.

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

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

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

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.

C macros definitely hinder all kinds of tooling.

Why add a new core feature, when some tacky, half-assed macro can be
used? Or, sometimes, a typedef.

But, tacky as the macro is, it only pollutes the program where it is
used, not the entire language.

A badly designed macro getting into a program is less harmful than a
badly designed feature getting into the language. (Where we recognize
that such a feature could be a macro.)

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]).

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.

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?

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca