On 20/04/2025 17:46, Janis Papanagnou wrote:
On 20.04.2025 13:43, bart wrote:
On 20/04/2025 11:18, Janis Papanagnou wrote:
On 19.04.2025 15:05, bart wrote:
>
But overloading in the form of 30-40 integer types to represent the 8
types i8-i64 and u8-u64, plus the 16 different combinations of writing
'unsigned long long int', and so on, is fine. As are the dozens
(hundreds?) of macros in stdint.h/inttypes.h.
I haven't said this "is fine". It wasn't at all the topic here.
Sorry, I forgot the rules. Only YOU are allowed to call adding one extra loop type 'overloading' of the language. But *I* am not allowed to call the plethora of integer types and support macros 'overloading' of the same language.
Show me a for-loop that cannot be expressed with existing features. Many
are likely to be clearer!
(There have been sufficient examples posted.)
In C? I don't recall any examples in C that could be written without 'for'.
It makes not much sense to spread them across a multi-line block
of statements. - If you haven't ever experienced that, and still
cannot see and understand that if explained to you, then I can't
help you.[*]
Here's the example you snipped:
for(p=sqliteHashFirst(&pSchema->trigHash); p; p=sqliteHashNext(p)){
sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p));
}
In my opinion, that for-header is too complex. You can barely make out the condition (that lonely 'p' which you have to hunt for).
> The point is that if you have programming elements that are
> related to a loop construct (initialization, exit condition,
> update for next iteration) it makes sense to keep them together.
So what about this then (another example you snipped):
for(p=sqliteHashFirst(&pSchema->trigHash); p; sqlite3DeleteTrigger(db, (Trigger*)sqliteHashData(p)), p=sqliteHashNext(p));
It keeps it even more together, which you seem to like.
[*] Maybe you should visit some University courses. Despite your
long programming history you really seem to miss some elementary
basic programming experiences. Or are you mentally so bound to
primitive loops and your brain so inflexible that nothing helps.
I think it is YOU whose brain is so bound to having just the ONE kind of loop to do half a dozen different jobs, none of them well.
I don't know why people think that cramming as much code as possible
into for(...) is a good style of coding.
But that's not what programmers should do.
But they do! Try looking at hundreds of thousands of lines of open source projects like I do.
Why do you again make
up things. - The point is to keep things together that belong
together.
Why are you so crazy about putting everything onto one line? You're saying that:
ONE; TWO; THREE
is always better than:
ONE;
TWO;
THREE;
This is usually agreed to be better coding style. The same applies to complex type declarations which everyone tells me should use typedefs to break them up.
But when 'for' is involved, it seems all common sense goes out the Window.
This is an example which I started off trying to simplify:
for (monthIdx = 0; monthIdx < 12 && yearDay >= yearDays[leapYear][monthIdx]; monthIdx++) ;
I simply can't see it. So the first step is to turn it into a while loop:
monthIdx = 0;
while (monthIdx < 12 && yearDay >= yearDays[leapYear][monthIdx])
monthIdx++;
Now at least I can see the condition! I'm sorry, but if prefer the original, then I don't want to have to debug or maintain your code.
Here I would go further and use a short loop index:
m = 0;
while (m < 12 && yearDay >= yearDays[leapYear][m]) ++m;
This one is a simple iteration:
for (character = 0; character <= 255; character++) {
At least I can see it. However this is simply crying out to be written as:
for (ch in 0..255)
You don't get that? You'd rather keep it long-winded because you can do linked-lists too?!
I just don't get the love. Or maybe, nobody here (perhaps apart from Keith) is willing to admit that there's anything wrong with 'for'.
So, you don't like the idea of having multiple simple features, each
with a well defined job that a compiler can check.
Why do you think so.
I merely noted that if you, as the language designer, let yourself
get triggered by feature wishes (whether they fit in your language
design or not) that this is not what I'd consider to be sensible.
Huh? I have very ordinary 'for' statements that are similar to dozens of other languages.
I said I tried one like C's, and it was never used. There is enough flexibility in the rest to deal with anything that comes up.
do { quit; } else { }
Re: do { quit; } else { }