Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: bart Newsgroups: comp.lang.c Subject: Re: Loops (was Re: do { quit; } else { }) Date: Sat, 19 Apr 2025 19:59:03 +0100 Organization: A noiseless patient Spider Lines: 125 Message-ID: References: <87a58mqt2o.fsf@nosuchdomain.example.com> <20250413072027.219@kylheku.com> <20250419090525.701@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sat, 19 Apr 2025 20:59:03 +0200 (CEST) Injection-Info: dont-email.me; posting-host="5c7860f03a8e4f1e49f90b82bdb5768f"; logging-data="2186475"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+vj2vGian1f84ohAmdhWBF" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:TONIz+s5oszUAJWKPd7OVgVIWQc= In-Reply-To: <20250419090525.701@kylheku.com> Content-Language: en-GB Bytes: 6628 On 19/04/2025 17:28, Kaz Kylheku wrote: > On 2025-04-19, bart wrote: >> On 19/04/2025 07:27, Janis Papanagnou wrote: >>> On 19.04.2025 00:27, bart wrote: >> >>>> So, yes, I think that is problematic, and the fault is with the >>>> language. This stuff isn't not hard to get right; even BASIC manages to >>>> FOR-loops properly. >>> >>> As so often explained to you, BASIC has a most primitive loop.[*] >> >> As has been so often pointed out, the vast majority of iterating loops >> can be accommodated by 'for i = a to b'. So in that case it is not >> primitive. >> >> However C's for-loop genuinely *IS* primitve. > > The abstraction level difference is very small between a loop which > supplies only holes where you plug in your tests and increments, and a > loop which sets up the tests and increments. > > (In this particular case, we can macro over the difference with > a primitve token-replacing preprocessor.) That's writing your own language on top. You shouldn't need to that to be able to use fundamental features! >>> If that's all you can intellectually handle you're obviously a lousy >>> programmer (and far from a software engineer). >> >> Do you undertand my reasons for saying what I do? >> >> Suppose that C had both its primitive loop, and one like Basic's (or >> like Awk's); would that be better? If so, why? > > We've shown that with preprocessing it does: > > #define for_range(var, from, to) ... > > it's hard to define it so that it is absolutely correct, > able to handle an int variable going up to INT_MAX. But, nobody really cares about that. I say more about this later. > >> In fact, WHY does Awk have that other kind of loop? Since the primitive >> form can express it just as well. > > No, it cannot. The Awk for (x in array) loop is not easily > reproduced with the regular for loop. > > It has to step x through the keys of the associative array. > > To do it with a low level loop, we need the primitive stepping > operations: > > for (iter = array_first(array); > array_more(iter) && key = array_get(iter) > iter = array_next(iter)) > { > # key is set to successive keys > } > > Not only is this extremely clumsy, but those operations > don't even exist. There is no associative array iterating > object! I took the example of Awk that was using 'for in' and wrote it like this: split ("one two three four five", table) for (i=1; i<=5; i++) print i, table[i] It seemed to work. That it may have unrelated issues with associative arrays is another matter. > In my cppawk project there is a predefined keys (var, array) clause you > can use in the loop macro. > > Under the hood, this actually obtains a list of the keys as a Lisp-like > list, and then iterates over that. (Other approaches could be used, > like a function which converts the *keys* of a given array into > the *values* of a new array, that new array being indexed numerically > from zero. We could then step over these with i = 0 ... i++. In my script language I can get a helper function to produce a linear list of keys then iterate over that with a regular loop. My original example used an array of strings, which JP changed to an Awk table in order to show off Awk's 'for in'. They haven't yet explained why a normal loop and normal indexing work. >> I've written many 10s of 1000s of lines of assembly. But I prefer HLL >> code, and HLL code which has some must-have fundamentals. Like a fucking >> loop that works. > > But you yourself wrote such a loop that is broken; it has undefined > behavior when you go to the maximum value of the signed type. The behaviour is defined: it wraps round and the loop keeps going. But even if it went nowhere near the limits of the type, such a loop could keep going for a lifetime given a large enough range. You don't seem that bothered about that. In both cases the user would have to abort the program. > That's worse than a 100% correct primitive loop in which if such a > situation occurs, it is in plain sight, caused by the expressions > the programmer chose to plug into it. > > I told you I would rub this in your face! As I said, I don't care. Few people do, especially if working with 64 bits. I also said I worked out how to fix it in my language, but won't be doing so since it changes the language spec a little, and doesn't help with the other problem mentioned above, which is to do with sanitising for-loop ranges. This is more to do with user code, not language.