Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #403919 > unrolled thread
| Started by | fir <profesor.fir@gmail.com> |
|---|---|
| First post | 2026-11-01 14:32 +0100 |
| Last post | 2026-11-03 13:29 +0100 |
| Articles | 20 on this page of 90 — 7 participants |
Back to article view | Back to comp.lang.c
p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-01 14:32 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-01 13:41 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-01 15:10 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-01 16:13 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-02 16:46 +0100
Re: p = {1,0,0} David Brown <david.brown@hesbynett.no> - 2026-11-02 17:36 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-02 18:47 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-02 20:54 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-02 20:56 +0100
Re: p = {1,0,0} David Brown <david.brown@hesbynett.no> - 2026-11-02 21:29 +0100
Re: p = {1,0,0} Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-11-02 21:39 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-02 22:58 +0000
Re: p = {1,0,0} David Brown <david.brown@hesbynett.no> - 2026-11-03 11:09 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 13:19 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-03 14:07 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 15:45 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 15:54 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 16:48 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 14:29 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 14:42 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 16:09 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 16:18 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 16:38 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 16:55 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 17:06 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-03 16:26 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 17:34 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 17:47 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 17:54 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 22:08 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-04 14:14 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-04 14:27 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-05 19:10 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-05 19:38 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-07 20:14 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-07 20:18 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-07 20:19 +0100
Re: p = {1,0,0} Richard Harnden <richard.nospam@gmail.invalid> - 2026-11-08 09:29 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-07 20:24 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-07 20:26 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-07 22:18 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 04:17 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-07 20:50 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-07 22:23 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 04:20 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 04:36 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 04:46 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 16:20 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-08 17:18 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 19:17 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 19:36 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 19:41 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-08 11:19 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 12:44 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 12:56 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 13:12 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-08 16:12 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-09 23:47 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-09 23:56 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-10 01:11 +0000
Re: p = {1,0,0} David Brown <david.brown@hesbynett.no> - 2026-11-10 09:24 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-10 12:08 +0000
Re: p = {1,0,0} David Brown <david.brown@hesbynett.no> - 2026-11-10 13:50 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-10 13:53 +0000
while() and do/while() Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-11-10 11:47 -0800
Re: while() and do/while() bartc <bc@freeuk.com> - 2026-11-10 20:33 +0000
Re: p = {1,0,0} Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-11-10 04:29 -0800
Re: p = {1,0,0} David Brown <david.brown@hesbynett.no> - 2026-11-10 13:57 +0100
Re: p = {1,0,0} Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-11-10 08:57 -0800
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 13:51 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 14:08 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 14:17 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 14:22 +0100
Re: p = {1,0,0} bartc <bc@freeuk.com> - 2026-11-10 14:27 +0000
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:32 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:44 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:51 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 16:10 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 16:24 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 16:38 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 16:54 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 17:09 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 17:16 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 17:20 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:09 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:13 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:17 +0100
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-10 15:24 +0100
Re: p = {1,0,0} Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-11-02 14:52 -0800
Re: p = {1,0,0} fir <profesor.fir@gmail.com> - 2026-11-03 13:29 +0100
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-11-10 09:24 +0100 |
| Message-ID | <11cukc4$1vnj7$1@dont-email.me> |
| In reply to | #404172 |
On 10/11/2026 02:11, bartc wrote:
> On 09/11/2026 22:47, fir wrote:
>> yet maybe some thoughts on for loop syntax potential improvements
>>
>>
>>
>>
>>
>>
>> im really annoyed by long c loops
>> like for(int i=0; i<100; i++) {}
>
> So am I.
>
>> back hen i miraculously mabe found some good alternative but it needs
>> unicode
>
> But there are a million ways to have a shorter syntax without needing to
> resort to Unicode.
>
> Have you looked at /any/ other at languages at all? Take some ideas from
> those.
Or look at C. It is not exactly a challenge to have :
#define For(_var, _limit) for (int _var = 0; _var < _limit; _var++)
and then you can write :
For(i, 100)
With a little more effort, you can even make a single macro that could
handle :
For(100) // Automatic anonymous variable
and
For(i, 1, 100) // If you don't want to start at 0
It is ludicrous to get annoyed about the "lack" of a feature in a
language when the language has all you need in order to provide that
feature. (It is fine to say you would /prefer/ if this feature were
available out-of-the-box in C - that's just personal preference.)
(And before you say it, this is not a "workaround". Macros are part of
the language - they are there to be used if the programmer thinks the
resulting code is better. I personally don't think such a "For" macro
would give better code, but my preferences are different from yours.)
>
>> 100𝐢 {} //is alternative for "for(int i=0; i<100; i++) {}"
>
> for i<100 {}
>
> might do it too. But I'd prefer 'for i=0,100 {}'.
>
>> if f() is a function call then
>>
>> f();f();f();f();f();f();f();f();
>>
>> resembles loop thus
>>
>> f()^10 may be understand as a kinda "natural" form of loop
Symbols are fine for things that are used a lot. For rarely used
features, they are hard to remember when either reading or writing the
code. And this would never be used.
>>
>
> So a repeat-N-times loop. Try ntimes 10 {}
#define NTimes(_n) for (int _nnn = 0; _nnn < _n; _nnn++)
>
>> so
>>
>> int i =0; {a[i++]==0? break} ^ strlen(a);
>>
>> might be seen as kinda natural
>> (probably thought here strlen would be called many tiles so maybe
>>
>> int LEN = strlen(a);
>> int i =0; {a[i++]==0? break} ^ LEN;
>
> How you have a loop that iterates over 0 to LEN-1, and yet you still
> have a repeat-N-times loop and need to manually initialise and step the
> index?
>
> Try the idea from above (upper limit is exclusive):
>
> for i=0,strlen(a) {a[i]==0 ? break}
>
> (I won't comment on that ? construct.)
>
The big trouble with playing syntax games like Fir is doing (and you are
doing, to a lesser extent) is that it is very easy to write code
snippets as examples, but very difficult to make a complete set of
syntax and grammar rules that are not ambiguous or in conflict with each
other. Fir does not need to consider that at all in his ramblings - he
just lets his cat wander across his keyboard. For a real language for
widespread use, it is far more difficult as you have to consider all
conceivable corner cases or strange usage. (For your languages, Bart,
you have a middle ground - since you are the only user, you can easily
ensure that all users stay away from awkward corner cases. That's
entirely fine for your own use - but it is one of the reasons your
language design does not scale or compare to mainstream languages.
Still, I would far rather work with your choices than Fir's here!)
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2026-11-10 12:08 +0000 |
| Message-ID | <11cv1ft$24amr$1@dont-email.me> |
| In reply to | #404177 |
On 10/11/2026 08:24, David Brown wrote:
> On 10/11/2026 02:11, bartc wrote:
>> Have you looked at /any/ other at languages at all? Take some ideas
>> from those.
>
> Or look at C. It is not exactly a challenge to have :
>
> #define For(_var, _limit) for (int _var = 0; _var < _limit; _var++)
>
> and then you can write :
>
> For(i, 100)
>
> With a little more effort, you can even make a single macro that could
> handle :
>
> For(100) // Automatic anonymous variable
>
> and
>
> For(i, 1, 100) // If you don't want to start at 0
This is stuff I used to do. Then I realised then using a private macro
library to refine the language doesn't work (when posting code on forums
for example).
>> Try the idea from above (upper limit is exclusive):
>>
>> for i=0,strlen(a) {a[i]==0 ? break}
>>
>> (I won't comment on that ? construct.)
>>
>
> The big trouble with playing syntax games like Fir is doing (and you are
> doing, to a lesser extent) is that it is very easy to write code
> snippets as examples, but very difficult to make a complete set of
> syntax and grammar rules that are not ambiguous or in conflict with each
> other. Fir does not need to consider that at all in his ramblings - he
> just lets his cat wander across his keyboard. For a real language for
> widespread use,
The examples I gave here were just starting points: saner ideas
(compared to /needing/ Unicode for identifiers for example). But they
are based on real features used elsewhere.
They are vaguely C-like, but whatever fir is planning is a long way from
C anyway. He's not interested in workarounds using actual C.
> it is far more difficult as you have to consider all
> conceivable corner cases or strange usage. (For your languages, Bart,
> you have a middle ground - since you are the only user, you can easily
> ensure that all users stay away from awkward corner cases.
A language only needs to be real, not widespread, for the syntax choices
to be valid. There is nothing wrong or ambiguous about the grammar used
for my loop constructs.
This kind of feature is one of the simplest to get right in a language,
especially when it is 1-based.
0-based languages make ranges a little more ambiguous. (I believe Zig
held back on having an iterative for-statement because of this, since
the upper bounds usually needs to be exclusive.)
Or do you mean that what I have is not as flexible as a C-style
for-loop? That would be true. The nearest thing I have to:
for (A; B; C) {
is:
A
while B, C do
(This had been a suggested replacement for C's for-loop, which I
implemented as a proof-of-concept. I decided to keep the feature and use
it for linked-list traversal, the primary use-case when people explain
why C for-loops are better.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-11-10 13:50 +0100 |
| Message-ID | <11cv3vb$257i8$1@dont-email.me> |
| In reply to | #404180 |
On 10/11/2026 13:08, bartc wrote: > On 10/11/2026 08:24, David Brown wrote: >> On 10/11/2026 02:11, bartc wrote: > >>> Have you looked at /any/ other at languages at all? Take some ideas >>> from those. >> >> Or look at C. It is not exactly a challenge to have : >> >> #define For(_var, _limit) for (int _var = 0; _var < _limit; _var++) >> >> and then you can write : >> >> For(i, 100) >> >> With a little more effort, you can even make a single macro that could >> handle : >> >> For(100) // Automatic anonymous variable >> >> and >> >> For(i, 1, 100) // If you don't want to start at 0 > > This is stuff I used to do. Then I realised then using a private macro > library to refine the language doesn't work (when posting code on forums > for example). Well, it works perfectly well in that it does exactly what you are asking for here. It is common to have small libraries with functions, headers, macros, typedefs, inline static functions, etc., that you re-use between projects. And if you really want such a "For" feature, because you really don't like C's "for" loops, and its your code, then use it. No one else gets to tell you how you write your own code. But if the code is to be shared with others, then you have to consider what suits those other people. And if you are sharing small bits of code on Usenet (or other discussion forum), it is a lot easier if the code is written in a fashion familiar to other people, without extra abstractions, and certainly without extra dependencies. That's nothing special about C or macros - it's just basic communication skills. > > They are vaguely C-like, but whatever fir is planning is a long way from > C anyway. He's not interested in workarounds using actual C. > Agreed. I have no idea what he is actually interested in, and don't bother replying to him. (I might follow-up on a post he makes if I think it is interesting in the C context or could be of interest to someone else here, but I think trying to figure out what he wants or trying to help him directly is a lost cause.) >> it is far more difficult as you have to consider all conceivable >> corner cases or strange usage. (For your languages, Bart, you have a >> middle ground - since you are the only user, you can easily ensure >> that all users stay away from awkward corner cases. > > A language only needs to be real, not widespread, for the syntax choices > to be valid. There is nothing wrong or ambiguous about the grammar used > for my loop constructs. > > This kind of feature is one of the simplest to get right in a language, > especially when it is 1-based. The very fact that you think this is something to "get right" shows where you go wrong in language design, language comparison, and language discussions. It is one of the key reasons why you get in arguments with so many people here (the other being that your language has no relevance to comp.lang.c, or anyone other than yourself). It is fine to /prefer/ one construct or syntax over another, or to think that one fits better in a given language. It is quite a different matter to claim that your way is "right" and everyone else is "wrong".
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2026-11-10 13:53 +0000 |
| Message-ID | <11cv7lo$26k3l$1@dont-email.me> |
| In reply to | #404182 |
On 10/11/2026 12:50, David Brown wrote:
> On 10/11/2026 13:08, bartc wrote:
>> A language only needs to be real, not widespread, for the syntax
>> choices to be valid. There is nothing wrong or ambiguous about the
>> grammar used for my loop constructs.
>>
>> This kind of feature is one of the simplest to get right in a
>> language, especially when it is 1-based.
>
> The very fact that you think this is something to "get right" shows
> where you go wrong in language design, language comparison, and language
> discussions.
Then I don't understand your point here:
"it is far more difficult as you have to consider all conceivable corner
cases or strange usage."
I directly support these kinds of loops:
endless
N-times
while/repeat-until
iterate over ranges or values
(a fifth category not relevant here)
Given those, then the semantics and implementations can be
straightforward. I can't see the corner cases you mentioned (except when
operating at extreme integer values), therefore there is little to get
wrong.
BTW, C only directly supports that third category as while/do-while.
Plus some construction it calls 'for', which is a kind of DIY toolkit
for constructing any manner of weird and wonderful loops, that cannot be
verified for correctness.
So did C 'get it right' here? Since there are so many ways for /users/
to inadvertently get it wrong while still ending up with valid syntax
('for(i=0; j<=n; ++k)').
(I suggested you'd meant the lack of a statement like this in my
projects. Well, I did have it for a year or two, but having /never/ used
it, it got dropped.
Anyway, how does C get away with having 'while' both starting a loop
statement, and ending one?!)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-11-10 11:47 -0800 |
| Subject | while() and do/while() |
| Message-ID | <86tslompsu.fsf_-_@linuxsc.com> |
| In reply to | #404190 |
bartc <bc@freeuk.com> writes: > Anyway, how does C get away with having 'while' both starting a > loop statement, and ending one?!) What is it that you think C is getting away with by having both while() and do/while() loop forms?
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2026-11-10 20:33 +0000 |
| Subject | Re: while() and do/while() |
| Message-ID | <11cvv36$2g0f7$1@dont-email.me> |
| In reply to | #404212 |
On 10/11/2026 19:47, Tim Rentsch wrote:
> bartc <bc@freeuk.com> writes:
>
>> Anyway, how does C get away with having 'while' both starting a
>> loop statement, and ending one?!)
>
> What is it that you think C is getting away with by having both
> while() and do/while() loop forms?
Mine was a light-hearted remark. Still, it /does/ get away with using
the same keyword for two different purposes.
So you, or a compiler, encounters 'while': is that starting a new
while-loop, or terminating a do-while loop? A fragment like this:
...
while (*s++ = *t++);
could be either unless you know what '...' is.
You need to delve into the grammar to see how it works:
do stmt while(); // 'while' terminates 'do'
do while() ... // 'while' is a while-loop inside do-while
... while() // independent while-loop provided this is
// not that first case
So the 'while' on the first line will get consumed when parsing 'do stmt
while' before it can be interpreted as a stand-alone statement.
The cost is needing to always have exactly 1 statement for the body of
do-while. 2 or more need a compound statement, and 0 statements is not
allowed.
(I can't have repeat-while in my own projects because it would be
ambiguous. But there I can have 0, 1 or more statements within the body,
and any can legally be nested while-statements.
I have to use repeat-until which has the opposite logic.)
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2026-11-10 04:29 -0800 |
| Message-ID | <11cv2mt$24ofb$1@kst.eternal-september.org> |
| In reply to | #404177 |
David Brown <david.brown@hesbynett.no> writes:
[...]
> Or look at C. It is not exactly a challenge to have :
>
> #define For(_var, _limit) for (int _var = 0; _var < _limit; _var++)
>
> and then you can write :
>
> For(i, 100)
>
> With a little more effort, you can even make a single macro that could
> handle :
>
> For(100) // Automatic anonymous variable
>
> and
>
> For(i, 1, 100) // If you don't want to start at 0
>
> It is ludicrous to get annoyed about the "lack" of a feature in a
> language when the language has all you need in order to provide that
> feature. (It is fine to say you would /prefer/ if this feature were
> available out-of-the-box in C - that's just personal preference.)
I don't entirely agree. Yes, you can create macros that make C
look like something else (I've done it myself). But any such
macro almost creates a new language that anyone reading the code
has to be familiar with.
If I see `For(100)`, I have to find out how it's defined *and*
understand the `for(...;...;...)` code that it expands to.8
If I thought C would benefit significantly from a Pascal-style for
loop (I don't), I'd want it added as a language feature, not hacked
by multiple incompatible macro definitions, one per project.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2026-11-10 13:57 +0100 |
| Message-ID | <11cv4c8$25c1j$1@dont-email.me> |
| In reply to | #404181 |
On 10/11/2026 13:29, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: > [...] >> Or look at C. It is not exactly a challenge to have : >> >> #define For(_var, _limit) for (int _var = 0; _var < _limit; _var++) >> >> and then you can write : >> >> For(i, 100) >> >> With a little more effort, you can even make a single macro that could >> handle : >> >> For(100) // Automatic anonymous variable >> >> and >> >> For(i, 1, 100) // If you don't want to start at 0 >> >> It is ludicrous to get annoyed about the "lack" of a feature in a >> language when the language has all you need in order to provide that >> feature. (It is fine to say you would /prefer/ if this feature were >> available out-of-the-box in C - that's just personal preference.) > > I don't entirely agree. Yes, you can create macros that make C > look like something else (I've done it myself). But any such > macro almost creates a new language that anyone reading the code > has to be familiar with. > > If I see `For(100)`, I have to find out how it's defined *and* > understand the `for(...;...;...)` code that it expands to.8 > > If I thought C would benefit significantly from a Pascal-style for > loop (I don't), I'd want it added as a language feature, not hacked > by multiple incompatible macro definitions, one per project. > For a feature that really is useful, and where the change really does make a big difference to the language, then I agree. A key indicator of that is when people /do/ make multiple incompatible definitions to provide the feature. (Booleans is a prime example for C.) When it is a minor matter that few people even think about, such as the way "for" loops are written in C, then it is entirely unrealistic to imagine it being added to the language. Given that, I think it would be better for bart to make and use a "For" macro in his own C programming (if he does any now), rather than getting annoyed about how "for" works. It would be even better for him to simply use C's "for" /without/ getting annoyed, if that is an option.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2026-11-10 08:57 -0800 |
| Message-ID | <86y0b0mxoo.fsf@linuxsc.com> |
| In reply to | #404181 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > If I thought C would benefit significantly from a Pascal-style for > loop (I don't), I'd want it added as a language feature, [...] Your statement is clear about what you want. Do you have any reasons to offer why anyone else should want it, or is it merely a statement of personal opinion?
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 13:51 +0100 |
| Message-ID | <11cv41a$2582a$1@dont-email.me> |
| In reply to | #404172 |
bartc pisze:
>
> for i=1,100 {tab[i]=0}
>
>
this on i dont like better woud be imo
for i = 1 to 100 {tab[i]=0}
but still it feels too much basic
there are quite few subtle things here what given form gives what feelings
note in c that has no loop there is like no "natural" form of loop
(unles maybe just raw goto etc) at least i dont see it
this one wth power may be koncidered as somewhat natural
{ } ^ t
(note my rider turned some ^100 to superscripts when i posted post in
text i meant ^ 100 not superscripts (unless the last ones (tab[i++]
superscript 100)
i could made soem misteke coz when i consider
10 ^ t {} //read like 10 times "power" {} indexed by t
against
t ^ 10 {} //same
then the first one seems more appropriate
also
1..29 ^ t {}
a..b ^ i {}
imo this above is beter than
int i =a,b {} //<-- in this you take very rouhg (and) syntactic
decision imo (lk egeneralli a,b in c is considered like {a,b} so
it noramlly woud be {int i=a, b} tuple of things ..if no such thing as
i = {a, b} is not defined and if it looks liek it would like be defined
its definitely not like in for loop etc
the decisions behind
a..b ^ i {}
are imo quitte different and less colliding
(i know ^ is for xor etc, though i dont like tose bitwise operators as
thei are taken in c at allso, eventually some could substitute ^ with
something other its secondary
a..b @ i {}
(i slightly prefer here a..b ^ i {} right now but the exact symbol
choices can be deferred)
//i also konsidered
a..b {tab[%1]=k}
//%1 being replcement for i - but i has good tradition in c
// but maybe it could be also present as an alternative solution
so right now from those considerations the ground im standing
as to loops would be that
1..29𝐭{tab[𝐭]=9}
1..29 ^ t {tab[t]=9}
1..29 {tab[%1]=9}
// maybe 1..29 ^ {tab[%1]=9}
//maybe ^ t =1..29 {tab[%1]=9}
// alternatively {tab[%1]=9} ^ t= 1..76
//well in combination with power this assigment dont look bad here
maybe this also?
^ t=1..29 {tab[t]=9}
allows
^ t = {2,7,9,7,2,4,5} {f(t)}
//allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
here this leftside form tooks weird more proper lik rightside
{ f(t)} ^ t = {2,7,9,7,2,4,5}
{ f(t)} ^ t = 2..50
overally not bad idea - power combined with those "value lists" either
a..b or {a,b,c}
//i put space among "^ t" artifically to editor not turn it in
superscript normally no space needed
maybe its even better than this unicode version
this may be also considered
T = {2,3,4,6} ;
foo(T);
normally it would just pass a tuple so maybe some operator for "pass
sequentially in time" is maybe needed
T = {2,3,4,6} ;
foo(::T);
foo(^{2,3,4,6});
i dont know somethig could be taken
but if soe some could call few sets in parallel so tt fould need to be
organized someway
foo(^{2,3,4,6}, ^{0,0,3,4});
foo(^{{2,0}{3,0}{4,3}{6,4}});
its also ok it semms you can pass it to whole block
{ } ^ t= {3,4,5}
as what it was started here
overally it gives both a loop syntax and new posibilities so its quite
interesting path
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 14:08 +0100 |
| Message-ID | <11cv50h$25kba$1@dont-email.me> |
| In reply to | #404183 |
fir pisze:
> bartc pisze:
>>
>> for i=1,100 {tab[i]=0}
>>
>>
>
> this on i dont like better woud be imo
>
> for i = 1 to 100 {tab[i]=0}
>
> but still it feels too much basic
>
> there are quite few subtle things here what given form gives what feelings
>
> note in c that has no loop there is like no "natural" form of loop
> (unles maybe just raw goto etc) at least i dont see it
>
> this one wth power may be koncidered as somewhat natural
>
> { } ^ t
>
> (note my rider turned some ^100 to superscripts when i posted post in
> text i meant ^ 100 not superscripts (unless the last ones (tab[i++]
> superscript 100)
>
> i could made soem misteke coz when i consider
>
> 10 ^ t {} //read like 10 times "power" {} indexed by t
>
> against
>
>
> t ^ 10 {} //same
>
> then the first one seems more appropriate
>
>
> also
>
> 1..29 ^ t {}
>
> a..b ^ i {}
>
> imo this above is beter than
>
> int i =a,b {} //<-- in this you take very rouhg (and) syntactic
> decision imo (lk egeneralli a,b in c is considered like {a,b} so
> it noramlly woud be {int i=a, b} tuple of things ..if no such thing as
> i = {a, b} is not defined and if it looks liek it would like be defined
> its definitely not like in for loop etc
>
> the decisions behind
>
> a..b ^ i {}
>
> are imo quitte different and less colliding
>
> (i know ^ is for xor etc, though i dont like tose bitwise operators as
> thei are taken in c at allso, eventually some could substitute ^ with
> something other its secondary
>
> a..b @ i {}
>
> (i slightly prefer here a..b ^ i {} right now but the exact symbol
> choices can be deferred)
>
> //i also konsidered
>
> a..b {tab[%1]=k}
>
>
> //%1 being replcement for i - but i has good tradition in c
> // but maybe it could be also present as an alternative solution
>
> so right now from those considerations the ground im standing
> as to loops would be that
>
> 1..29𝐭{tab[𝐭]=9}
>
> 1..29 ^ t {tab[t]=9}
>
> 1..29 {tab[%1]=9}
>
> // maybe 1..29 ^ {tab[%1]=9}
> //maybe ^ t =1..29 {tab[%1]=9}
> // alternatively {tab[%1]=9} ^ t= 1..76
>
> //well in combination with power this assigment dont look bad here
>
> maybe this also?
> ^ t=1..29 {tab[t]=9}
> allows
>
> ^ t = {2,7,9,7,2,4,5} {f(t)}
>
> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
>
> here this leftside form tooks weird more proper lik rightside
>
>
> { f(t)} ^ t = {2,7,9,7,2,4,5}
>
>
>
>
> { f(t)} ^ t = 2..50
>
> overally not bad idea - power combined with those "value lists" either
> a..b or {a,b,c}
> //i put space among "^ t" artifically to editor not turn it in
> superscript normally no space needed
>
> maybe its even better than this unicode version
>
> this may be also considered
>
>
> T = {2,3,4,6} ;
>
> foo(T);
>
> normally it would just pass a tuple so maybe some operator for "pass
> sequentially in time" is maybe needed
>
>
> T = {2,3,4,6} ;
>
> foo(::T);
>
> foo(^{2,3,4,6});
>
> i dont know somethig could be taken
>
> but if soe some could call few sets in parallel so tt fould need to be
> organized someway
>
> foo(^{2,3,4,6}, ^{0,0,3,4});
>
>
> foo(^{{2,0}{3,0}{4,3}{6,4}});
>
> its also ok it semms you can pass it to whole block
>
> { } ^ t= {3,4,5}
>
> as what it was started here
>
> overally it gives both a loop syntax and new posibilities so its quite
> interesting path
>
>
ok so after those above considerations
(becouse i know not many can go thru them)
{} ^ t=2..99; //call {} 98 times
is good
and
{} ^ t ={2,3,1,2,3,88}; //call {} six times
it also probbaly need leftside form (normally power has no leftside form)
and it also need those form where you put this "powerings" inside
tab[^T] = ^S
where
int T = {2,8,9,100}; char* S = {"ahbahj","sds","Sdsd","sss"};
maybe - or somethig like that (as to those inner forms im not yet sure)
i must give kudos to bartc
this one
{} ^ t=2..99;
a bit resembles for int i = 2,30 though there are notable
differences - this for is wrong (becouse on abstract level this above is
not looping its more like powering so its 'abstract' looping
(and really that gives difference becouse if you go on some abstract
train of thjoughts the rails are different here)..also thi basic burden
and all that classical syntax dont fit its another vision
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 14:17 +0100 |
| Message-ID | <11cv5ih$25r8c$1@dont-email.me> |
| In reply to | #404185 |
fir pisze:
> fir pisze:
>> bartc pisze:
>>>
>>> for i=1,100 {tab[i]=0}
>>>
>>>
>>
>> this on i dont like better woud be imo
>>
>> for i = 1 to 100 {tab[i]=0}
>>
>> but still it feels too much basic
>>
>> there are quite few subtle things here what given form gives what
>> feelings
>>
>> note in c that has no loop there is like no "natural" form of loop
>> (unles maybe just raw goto etc) at least i dont see it
>>
>> this one wth power may be koncidered as somewhat natural
>>
>> { } ^ t
>>
>> (note my rider turned some ^100 to superscripts when i posted post in
>> text i meant ^ 100 not superscripts (unless the last ones (tab[i++]
>> superscript 100)
>>
>> i could made soem misteke coz when i consider
>>
>> 10 ^ t {} //read like 10 times "power" {} indexed by t
>>
>> against
>>
>>
>> t ^ 10 {} //same
>>
>> then the first one seems more appropriate
>>
>>
>> also
>>
>> 1..29 ^ t {}
>>
>> a..b ^ i {}
>>
>> imo this above is beter than
>>
>> int i =a,b {} //<-- in this you take very rouhg (and) syntactic
>> decision imo (lk egeneralli a,b in c is considered like {a,b} so
>> it noramlly woud be {int i=a, b} tuple of things ..if no such thing as
>> i = {a, b} is not defined and if it looks liek it would like be
>> defined its definitely not like in for loop etc
>>
>> the decisions behind
>>
>> a..b ^ i {}
>>
>> are imo quitte different and less colliding
>>
>> (i know ^ is for xor etc, though i dont like tose bitwise operators as
>> thei are taken in c at allso, eventually some could substitute ^ with
>> something other its secondary
>>
>> a..b @ i {}
>>
>> (i slightly prefer here a..b ^ i {} right now but the exact symbol
>> choices can be deferred)
>>
>> //i also konsidered
>>
>> a..b {tab[%1]=k}
>>
>>
>> //%1 being replcement for i - but i has good tradition in c
>> // but maybe it could be also present as an alternative solution
>>
>> so right now from those considerations the ground im standing
>> as to loops would be that
>>
>> 1..29𝐭{tab[𝐭]=9}
>>
>> 1..29 ^ t {tab[t]=9}
>>
>> 1..29 {tab[%1]=9}
>>
>> // maybe 1..29 ^ {tab[%1]=9}
>> //maybe ^ t =1..29 {tab[%1]=9}
>> // alternatively {tab[%1]=9} ^ t= 1..76
>>
>> //well in combination with power this assigment dont look bad here
>>
>> maybe this also?
>> ^ t=1..29 {tab[t]=9}
>> allows
>>
>> ^ t = {2,7,9,7,2,4,5} {f(t)}
>>
>> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
>>
>> here this leftside form tooks weird more proper lik rightside
>>
>>
>> { f(t)} ^ t = {2,7,9,7,2,4,5}
>>
>>
>>
>>
>> { f(t)} ^ t = 2..50
>>
>> overally not bad idea - power combined with those "value lists" either
>> a..b or {a,b,c}
>> //i put space among "^ t" artifically to editor not turn it in
>> superscript normally no space needed
>>
>> maybe its even better than this unicode version
>>
>> this may be also considered
>>
>>
>> T = {2,3,4,6} ;
>>
>> foo(T);
>>
>> normally it would just pass a tuple so maybe some operator for "pass
>> sequentially in time" is maybe needed
>>
>>
>> T = {2,3,4,6} ;
>>
>> foo(::T);
>>
>> foo(^{2,3,4,6});
>>
>> i dont know somethig could be taken
>>
>> but if soe some could call few sets in parallel so tt fould need to be
>> organized someway
>>
>> foo(^{2,3,4,6}, ^{0,0,3,4});
>>
>>
>> foo(^{{2,0}{3,0}{4,3}{6,4}});
>>
>> its also ok it semms you can pass it to whole block
>>
>> { } ^ t= {3,4,5}
>>
>> as what it was started here
>>
>> overally it gives both a loop syntax and new posibilities so its quite
>> interesting path
>>
>>
>
> ok so after those above considerations
> (becouse i know not many can go thru them)
>
> {} ^ t=2..99; //call {} 98 times
>
> is good
>
> and
>
> {} ^ t ={2,3,1,2,3,88}; //call {} six times
>
>
> it also probbaly need leftside form (normally power has no leftside form)
>
> and it also need those form where you put this "powerings" inside
>
> tab[^T] = ^S
>
> where
>
> int T = {2,8,9,100}; char* S = {"ahbahj","sds","Sdsd","sss"};
>
>
> maybe - or somethig like that (as to those inner forms im not yet sure)
>
> i must give kudos to bartc
>
>
> this one
>
> {} ^ t=2..99;
>
> a bit resembles for int i = 2,30 though there are notable
> differences - this for is wrong (becouse on abstract level this above is
> not looping its more like powering so its 'abstract' looping
> (and really that gives difference becouse if you go on some abstract
> train of thjoughts the rails are different here)..also thi basic burden
> and all that classical syntax dont fit its another vision
though for exampla this sign ^ imo could and mabe should be reead "for"
^T foo(T*3);
depending what T is
like int T = 1..29; //T is scope/range
int T = {2,3,4,55,5,3,4}; //t is list/vector/structure
foo(^T*3); probably can be used as a shortcut and
funnt "^" is read as for
so this is "short for" discovery i could say
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 14:22 +0100 |
| Message-ID | <11cv5qe$25u43$1@dont-email.me> |
| In reply to | #404186 |
fir pisze:
> fir pisze:
>> fir pisze:
>>> bartc pisze:
>>>>
>>>> for i=1,100 {tab[i]=0}
>>>>
>>>>
>>>
>>> this on i dont like better woud be imo
>>>
>>> for i = 1 to 100 {tab[i]=0}
>>>
>>> but still it feels too much basic
>>>
>>> there are quite few subtle things here what given form gives what
>>> feelings
>>>
>>> note in c that has no loop there is like no "natural" form of loop
>>> (unles maybe just raw goto etc) at least i dont see it
>>>
>>> this one wth power may be koncidered as somewhat natural
>>>
>>> { } ^ t
>>>
>>> (note my rider turned some ^100 to superscripts when i posted post in
>>> text i meant ^ 100 not superscripts (unless the last ones (tab[i++]
>>> superscript 100)
>>>
>>> i could made soem misteke coz when i consider
>>>
>>> 10 ^ t {} //read like 10 times "power" {} indexed by t
>>>
>>> against
>>>
>>>
>>> t ^ 10 {} //same
>>>
>>> then the first one seems more appropriate
>>>
>>>
>>> also
>>>
>>> 1..29 ^ t {}
>>>
>>> a..b ^ i {}
>>>
>>> imo this above is beter than
>>>
>>> int i =a,b {} //<-- in this you take very rouhg (and) syntactic
>>> decision imo (lk egeneralli a,b in c is considered like {a,b} so
>>> it noramlly woud be {int i=a, b} tuple of things ..if no such thing as
>>> i = {a, b} is not defined and if it looks liek it would like be
>>> defined its definitely not like in for loop etc
>>>
>>> the decisions behind
>>>
>>> a..b ^ i {}
>>>
>>> are imo quitte different and less colliding
>>>
>>> (i know ^ is for xor etc, though i dont like tose bitwise operators
>>> as thei are taken in c at allso, eventually some could substitute ^
>>> with something other its secondary
>>>
>>> a..b @ i {}
>>>
>>> (i slightly prefer here a..b ^ i {} right now but the exact symbol
>>> choices can be deferred)
>>>
>>> //i also konsidered
>>>
>>> a..b {tab[%1]=k}
>>>
>>>
>>> //%1 being replcement for i - but i has good tradition in c
>>> // but maybe it could be also present as an alternative solution
>>>
>>> so right now from those considerations the ground im standing
>>> as to loops would be that
>>>
>>> 1..29𝐭{tab[𝐭]=9}
>>>
>>> 1..29 ^ t {tab[t]=9}
>>>
>>> 1..29 {tab[%1]=9}
>>>
>>> // maybe 1..29 ^ {tab[%1]=9}
>>> //maybe ^ t =1..29 {tab[%1]=9}
>>> // alternatively {tab[%1]=9} ^ t= 1..76
>>>
>>> //well in combination with power this assigment dont look bad here
>>>
>>> maybe this also?
>>> ^ t=1..29 {tab[t]=9}
>>> allows
>>>
>>> ^ t = {2,7,9,7,2,4,5} {f(t)}
>>>
>>> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
>>>
>>> here this leftside form tooks weird more proper lik rightside
>>>
>>>
>>> { f(t)} ^ t = {2,7,9,7,2,4,5}
>>>
>>>
>>>
>>>
>>> { f(t)} ^ t = 2..50
>>>
>>> overally not bad idea - power combined with those "value lists"
>>> either a..b or {a,b,c}
>>> //i put space among "^ t" artifically to editor not turn it in
>>> superscript normally no space needed
>>>
>>> maybe its even better than this unicode version
>>>
>>> this may be also considered
>>>
>>>
>>> T = {2,3,4,6} ;
>>>
>>> foo(T);
>>>
>>> normally it would just pass a tuple so maybe some operator for "pass
>>> sequentially in time" is maybe needed
>>>
>>>
>>> T = {2,3,4,6} ;
>>>
>>> foo(::T);
>>>
>>> foo(^{2,3,4,6});
>>>
>>> i dont know somethig could be taken
>>>
>>> but if soe some could call few sets in parallel so tt fould need to
>>> be organized someway
>>>
>>> foo(^{2,3,4,6}, ^{0,0,3,4});
>>>
>>>
>>> foo(^{{2,0}{3,0}{4,3}{6,4}});
>>>
>>> its also ok it semms you can pass it to whole block
>>>
>>> { } ^ t= {3,4,5}
>>>
>>> as what it was started here
>>>
>>> overally it gives both a loop syntax and new posibilities so its
>>> quite interesting path
>>>
>>>
>>
>> ok so after those above considerations
>> (becouse i know not many can go thru them)
>>
>> {} ^ t=2..99; //call {} 98 times
>>
>> is good
>>
>> and
>>
>> {} ^ t ={2,3,1,2,3,88}; //call {} six times
>>
>>
>> it also probbaly need leftside form (normally power has no leftside form)
>>
>> and it also need those form where you put this "powerings" inside
>>
>> tab[^T] = ^S
>>
>> where
>>
>> int T = {2,8,9,100}; char* S = {"ahbahj","sds","Sdsd","sss"};
>>
>>
>> maybe - or somethig like that (as to those inner forms im not yet sure)
>>
>> i must give kudos to bartc
>>
>>
>> this one
>>
>> {} ^ t=2..99;
>>
>> a bit resembles for int i = 2,30 though there are notable
>> differences - this for is wrong (becouse on abstract level this above
>> is not looping its more like powering so its 'abstract' looping
>> (and really that gives difference becouse if you go on some abstract
>> train of thjoughts the rails are different here)..also thi basic
>> burden and all that classical syntax dont fit its another vision
>
> though for exampla this sign ^ imo could and mabe should be reead "for"
>
>
> ^T foo(T*3);
>
> depending what T is
>
> like int T = 1..29; //T is scope/range
>
> int T = {2,3,4,55,5,3,4}; //t is list/vector/structure
>
> foo(^T*3); probably can be used as a shortcut and
> funnt "^" is read as for
>
> so this is "short for" discovery i could say
>
>
>
allright, so a lot has cleared here
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2026-11-10 14:27 +0000 |
| Message-ID | <11cv9kd$27cfo$1@dont-email.me> |
| In reply to | #404183 |
On 10/11/2026 12:51, fir wrote:
> bartc pisze:
>>
>> for i=1,100 {tab[i]=0}
>>
>>
>
> this on i dont like better woud be imo
>
> for i = 1 to 100 {tab[i]=0}
>
> but still it feels too much basic
I'd considered using 1..100 and 1 to 100 but your aim seemed to be
conciseness. "1,100" is used in Lua.
> there are quite few subtle things here what given form gives what feelings
>
> note in c that has no loop there is like no "natural" form of loop
> (unles maybe just raw goto etc) at least i dont see it
>
> this one wth power may be koncidered as somewhat natural
>
> { } ^ t
I once used this:
(n || s)
for repeat-N-times. I decided that was too quaint.
(If a loop were to return a value, as happens in some languages, then
such a compact form can be desirable to use within expressions.)
> a..b @ i {}
>
> (i slightly prefer here a..b ^ i {} right now but the exact symbol
> choices can be deferred)
Have you considered what the construct 'x .. y', if it was part of the
syntax, could have lots of different uses. For example:
if x in a..b # test a within a range
A[i..j] # slicing
So it would not be obvious that a..b introduces a loop. I assume that
'a..b @ i {}' means this in my own syntax:
for i in a..b do end
Which one do you think is clearer? Further, it is possible to do
for i in x do end
where 'x' might be a range defined elsewhere, or some collection. Now
that '..' cue is missing since you'd have to write 'x @ i {}'. But in
your next example ...
> //i also konsidered
>
> a..b {tab[%1]=k}
the @i is also missing so you basically have:
x {}
Wasn't this the syntax for your composite struct/function definition?
>
> //%1 being replcement for i - but i has good tradition in c
> // but maybe it could be also present as an alternative solution
>
> so right now from those considerations the ground im standing
> as to loops would be that
>
> 1..29𝐭{tab[𝐭]=9}
>
> 1..29 ^ t {tab[t]=9}
>
> 1..29 {tab[%1]=9}
>
> // maybe 1..29 ^ {tab[%1]=9}
> //maybe ^ t =1..29 {tab[%1]=9}
> // alternatively {tab[%1]=9} ^ t= 1..76
In practice you don't have many fixed ranges like this; the upper limit
is usually tied to the bounds of 'tab', so how would that look? Maybe:
for &x in tab {x = 9}
where the '&x' means that x is a writeable reference to the element.
(C++ might have this.)
> //well in combination with power this assigment dont look bad here
>
> maybe this also?
> ^ t=1..29 {tab[t]=9}
> allows
>
> ^ t = {2,7,9,7,2,4,5} {f(t)}
>
> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
This is still just a form of:
for x in tab {}
For example:
for x in (2,7,9,7,2,4,5) {f(x)}
But this is more high-level. Just look at some other languages; it's all
been done!
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 15:32 +0100 |
| Message-ID | <11cv9vf$27gjo$1@dont-email.me> |
| In reply to | #404196 |
bartc pisze:
> On 10/11/2026 12:51, fir wrote:
>> bartc pisze:
>>>
>>> for i=1,100 {tab[i]=0}
>>>
>>>
>>
>> this on i dont like better woud be imo
>>
>> for i = 1 to 100 {tab[i]=0}
>>
>> but still it feels too much basic
>
> I'd considered using 1..100 and 1 to 100 but your aim seemed to be
> conciseness. "1,100" is used in Lua.
ye i know, ebverybody would consider it i guess
but that showed not the point it showed power idea beats the "what loop
turn is" (at least in my mind)..but it also showed that this "t=2..23"
in fact stays (but combined with power)
so imo
for i=1..100 {tab[i]=0}
this is wrong becouse its classical basic seeing of the loop
but
{tab[i]=0} ^ i=1..100
kinda wins the bank here (imo) (though still i could say im not sure if
this "=" here is not a bit problematic (maybe not but maybe}
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 15:44 +0100 |
| Message-ID | <11cvakb$27njc$1@dont-email.me> |
| In reply to | #404196 |
bartc pisze:
>
> the @i is also missing so you basically have:
>
> x {}
>
> Wasn't this the syntax for your composite struct/function definition?
well if x is range than not
in some cases you strictly need this for sign but in more narrow you dont
its interesting if some would do
int i = 100;
i {tab[i]=0}
eventually also could go,a d its minimalistic
(and i considered thse mininal forms long ago but
if they are like "600 800 tab[%2][%1]=9 " they cant use this
classic i j k - unles as above, which i here consider first time
after a context of "pow")
but its maybe too exaggeration
like
a {b++}
normally is a definition of module a that calls code b++,
it it showed above a is an int then definition would turn into loop
execution
hovever knowing the context of ^ as pow now even that can be considered
but such code i may be afraid becomes too heavy
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 15:51 +0100 |
| Message-ID | <11cvb34$27u3i$1@dont-email.me> |
| In reply to | #404196 |
bartc pisze:
> On 10/11/2026 12:51, fir wrote:
>> bartc pisze:
>>>
>>> for i=1,100 {tab[i]=0}
>>>
>>>
>>
>> this on i dont like better woud be imo
>>
>> for i = 1 to 100 {tab[i]=0}
>>
>> but still it feels too much basic
>
> I'd considered using 1..100 and 1 to 100 but your aim seemed to be
> conciseness. "1,100" is used in Lua.
>
>
>> there are quite few subtle things here what given form gives what
>> feelings
>>
>> note in c that has no loop there is like no "natural" form of loop
>> (unles maybe just raw goto etc) at least i dont see it
>>
>> this one wth power may be koncidered as somewhat natural
>>
>> { } ^ t
>
> I once used this:
>
> (n || s)
>
> for repeat-N-times. I decided that was too quaint.
>
> (If a loop were to return a value, as happens in some languages, then
> such a compact form can be desirable to use within expressions.)
>
>> a..b @ i {}
>>
>> (i slightly prefer here a..b ^ i {} right now but the exact symbol
>> choices can be deferred)
> Have you considered what the construct 'x .. y', if it was part of the
> syntax, could have lots of different uses. For example:
>
> if x in a..b # test a within a range
> A[i..j] # slicing
>
> So it would not be obvious that a..b introduces a loop. I assume that
> 'a..b @ i {}' means this in my own syntax:
>
> for i in a..b do end
>
> Which one do you think is clearer? Further, it is possible to do
>
> for i in x do end
>
> where 'x' might be a range defined elsewhere, or some collection. Now
> that '..' cue is missing since you'd have to write 'x @ i {}'. But in
> your next example ...
>
>
>> //i also konsidered
>>
>> a..b {tab[%1]=k}
>
> the @i is also missing so you basically have:
>
> x {}
>
> Wasn't this the syntax for your composite struct/function definition?
>
>>
>> //%1 being replcement for i - but i has good tradition in c
>> // but maybe it could be also present as an alternative solution
>>
>> so right now from those considerations the ground im standing
>> as to loops would be that
>>
>> 1..29𝐭{tab[𝐭]=9}
>>
>> 1..29 ^ t {tab[t]=9}
>>
>> 1..29 {tab[%1]=9}
>>
>> // maybe 1..29 ^ {tab[%1]=9}
>> //maybe ^ t =1..29 {tab[%1]=9}
>> // alternatively {tab[%1]=9} ^ t= 1..76
>
> In practice you don't have many fixed ranges like this; the upper limit
> is usually tied to the bounds of 'tab', so how would that look? Maybe:
>
> for &x in tab {x = 9}
>
> where the '&x' means that x is a writeable reference to the element.
> (C++ might have this.)
>
>> //well in combination with power this assigment dont look bad here
>>
>> maybe this also?
>> ^ t=1..29 {tab[t]=9}
>> allows
>>
>> ^ t = {2,7,9,7,2,4,5} {f(t)}
>>
>> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
>
> This is still just a form of:
>
> for x in tab {}
>
> For example:
>
> for x in (2,7,9,7,2,4,5) {f(x)}
>
> But this is more high-level. Just look at some other languages; it's all
> been done!
>
>
its obviously not becouse you dont put those for in loops in places
tab[^{1,3,7,9}] = 'corner';
did they do
tab[for x in {1,3,7,9}] = 'corner';
thet would looks weird..there are abstract differencies in some cyntax
idea which are not the same as shallow syntax comparisons
in fact it shows shortcut may be eventually used also
tab[1,3,7,9] = 'corner';
but thats static case
t[] = {1,7,9,3}
tab[t] = 'corner'
could also be used
so in fact indeed some ^ seem not mandatory
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 16:10 +0100 |
| Message-ID | <11cvc5l$28a7s$1@dont-email.me> |
| In reply to | #404199 |
fir pisze:
> bartc pisze:
>> On 10/11/2026 12:51, fir wrote:
>>> bartc pisze:
>>>>
>>>> for i=1,100 {tab[i]=0}
>>>>
>>>>
>>>
>>> this on i dont like better woud be imo
>>>
>>> for i = 1 to 100 {tab[i]=0}
>>>
>>> but still it feels too much basic
>>
>> I'd considered using 1..100 and 1 to 100 but your aim seemed to be
>> conciseness. "1,100" is used in Lua.
>>
>>
>>> there are quite few subtle things here what given form gives what
>>> feelings
>>>
>>> note in c that has no loop there is like no "natural" form of loop
>>> (unles maybe just raw goto etc) at least i dont see it
>>>
>>> this one wth power may be koncidered as somewhat natural
>>>
>>> { } ^ t
>>
>> I once used this:
>>
>> (n || s)
>>
>> for repeat-N-times. I decided that was too quaint.
>>
>> (If a loop were to return a value, as happens in some languages, then
>> such a compact form can be desirable to use within expressions.)
>>
>>> a..b @ i {}
>>>
>>> (i slightly prefer here a..b ^ i {} right now but the exact symbol
>>> choices can be deferred)
>> Have you considered what the construct 'x .. y', if it was part of the
>> syntax, could have lots of different uses. For example:
>>
>> if x in a..b # test a within a range
>> A[i..j] # slicing
>>
>> So it would not be obvious that a..b introduces a loop. I assume that
>> 'a..b @ i {}' means this in my own syntax:
>>
>> for i in a..b do end
>>
>> Which one do you think is clearer? Further, it is possible to do
>>
>> for i in x do end
>>
>> where 'x' might be a range defined elsewhere, or some collection. Now
>> that '..' cue is missing since you'd have to write 'x @ i {}'. But in
>> your next example ...
>>
>>
>>> //i also konsidered
>>>
>>> a..b {tab[%1]=k}
>>
>> the @i is also missing so you basically have:
>>
>> x {}
>>
>> Wasn't this the syntax for your composite struct/function definition?
>>
>>>
>>> //%1 being replcement for i - but i has good tradition in c
>>> // but maybe it could be also present as an alternative solution
>>>
>>> so right now from those considerations the ground im standing
>>> as to loops would be that
>>>
>>> 1..29𝐭{tab[𝐭]=9}
>>>
>>> 1..29 ^ t {tab[t]=9}
>>>
>>> 1..29 {tab[%1]=9}
>>>
>>> // maybe 1..29 ^ {tab[%1]=9}
>>> //maybe ^ t =1..29 {tab[%1]=9}
>>> // alternatively {tab[%1]=9} ^ t= 1..76
>>
>> In practice you don't have many fixed ranges like this; the upper
>> limit is usually tied to the bounds of 'tab', so how would that look?
>> Maybe:
>>
>> for &x in tab {x = 9}
>>
>> where the '&x' means that x is a writeable reference to the element.
>> (C++ might have this.)
>>
>>> //well in combination with power this assigment dont look bad here
>>>
>>> maybe this also?
>>> ^ t=1..29 {tab[t]=9}
>>> allows
>>>
>>> ^ t = {2,7,9,7,2,4,5} {f(t)}
>>>
>>> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
>>
>> This is still just a form of:
>>
>> for x in tab {}
>>
>> For example:
>>
>> for x in (2,7,9,7,2,4,5) {f(x)}
>>
>> But this is more high-level. Just look at some other languages; it's
>> all been done!
>>
>>
>
> its obviously not becouse you dont put those for in loops in places
>
> tab[^{1,3,7,9}] = 'corner';
>
> did they do
>
> tab[for x in {1,3,7,9}] = 'corner';
>
> thet would looks weird..there are abstract differencies in some cyntax
> idea which are not the same as shallow syntax comparisons
>
> in fact it shows shortcut may be eventually used also
>
>
> tab[1,3,7,9] = 'corner';
>
> but thats static case
>
>
> t[] = {1,7,9,3}
>
> tab[t] = 'corner'
>
> could also be used
>
> so in fact indeed some ^ seem not mandatory
>
>
note becouse this is important to realize:
is some has some deeper "behind a syntax" observations
then aspects of those abservations may open som enew pathes in code
thinking tha just shallowly comparing syntaxes (and not realizing the
"behind" side dfferences which are kinda invisible (untill youre very
good in all that, bein able to catch and compare this invisible "behind"
side ideas)
you may say X looks like other X (ehere X is piece of some syntax) - it
looks very close or it even may just look the same
if thhere are other ideas on "behind" sides of one X and other X
they are not he same - especially if one X with its behind ideas opens
some new syntax gates/corridors/pathes for things
right now after those combinations/considerations it seems:
to get a loop in c you must
"multiply or power" given block of code with "range or list"
(as i said its rather power but is kinda abstract power so i some way
one could also say its abstract operation of multiply, and in common
language if some has
"block" X "range"
"block" X "list"
some can say imo multiply some can say "power to" depending what is more
convenient (i the context of those sentence multiply fits, normally imo
power more fits, but both somewhat fits)
so
tab[2..88] this is a loop (as tab is multipied by range or powered by range)
tab[t] -if t is array - is also a loop (of size of length of t)
tab[2,36,7,3,2,4,5] - is aloso a loop (t turns)
tab[i] would be loop if i is scope/range, if i is sole value its not a loop
so ine can evenylually say that if i is value say 100 some can use ^ to
turn it into scope/range
int i = 0..100;
tab[i]=0; //loop (101 turns)
int i=100;
tab[i] = 0;// not loop
tab[^i] ; //loop (100 turns)
all that abstract powering ideas lead to that
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 16:24 +0100 |
| Message-ID | <11cvcvg$28l1o$1@dont-email.me> |
| In reply to | #404201 |
fir pisze:
> fir pisze:
>> bartc pisze:
>>> On 10/11/2026 12:51, fir wrote:
>>>> bartc pisze:
>>>>>
>>>>> for i=1,100 {tab[i]=0}
>>>>>
>>>>>
>>>>
>>>> this on i dont like better woud be imo
>>>>
>>>> for i = 1 to 100 {tab[i]=0}
>>>>
>>>> but still it feels too much basic
>>>
>>> I'd considered using 1..100 and 1 to 100 but your aim seemed to be
>>> conciseness. "1,100" is used in Lua.
>>>
>>>
>>>> there are quite few subtle things here what given form gives what
>>>> feelings
>>>>
>>>> note in c that has no loop there is like no "natural" form of loop
>>>> (unles maybe just raw goto etc) at least i dont see it
>>>>
>>>> this one wth power may be koncidered as somewhat natural
>>>>
>>>> { } ^ t
>>>
>>> I once used this:
>>>
>>> (n || s)
>>>
>>> for repeat-N-times. I decided that was too quaint.
>>>
>>> (If a loop were to return a value, as happens in some languages, then
>>> such a compact form can be desirable to use within expressions.)
>>>
>>>> a..b @ i {}
>>>>
>>>> (i slightly prefer here a..b ^ i {} right now but the exact symbol
>>>> choices can be deferred)
>>> Have you considered what the construct 'x .. y', if it was part of
>>> the syntax, could have lots of different uses. For example:
>>>
>>> if x in a..b # test a within a range
>>> A[i..j] # slicing
>>>
>>> So it would not be obvious that a..b introduces a loop. I assume that
>>> 'a..b @ i {}' means this in my own syntax:
>>>
>>> for i in a..b do end
>>>
>>> Which one do you think is clearer? Further, it is possible to do
>>>
>>> for i in x do end
>>>
>>> where 'x' might be a range defined elsewhere, or some collection. Now
>>> that '..' cue is missing since you'd have to write 'x @ i {}'. But in
>>> your next example ...
>>>
>>>
>>>> //i also konsidered
>>>>
>>>> a..b {tab[%1]=k}
>>>
>>> the @i is also missing so you basically have:
>>>
>>> x {}
>>>
>>> Wasn't this the syntax for your composite struct/function definition?
>>>
>>>>
>>>> //%1 being replcement for i - but i has good tradition in c
>>>> // but maybe it could be also present as an alternative solution
>>>>
>>>> so right now from those considerations the ground im standing
>>>> as to loops would be that
>>>>
>>>> 1..29𝐭{tab[𝐭]=9}
>>>>
>>>> 1..29 ^ t {tab[t]=9}
>>>>
>>>> 1..29 {tab[%1]=9}
>>>>
>>>> // maybe 1..29 ^ {tab[%1]=9}
>>>> //maybe ^ t =1..29 {tab[%1]=9}
>>>> // alternatively {tab[%1]=9} ^ t= 1..76
>>>
>>> In practice you don't have many fixed ranges like this; the upper
>>> limit is usually tied to the bounds of 'tab', so how would that look?
>>> Maybe:
>>>
>>> for &x in tab {x = 9}
>>>
>>> where the '&x' means that x is a writeable reference to the element.
>>> (C++ might have this.)
>>>
>>>> //well in combination with power this assigment dont look bad here
>>>>
>>>> maybe this also?
>>>> ^ t=1..29 {tab[t]=9}
>>>> allows
>>>>
>>>> ^ t = {2,7,9,7,2,4,5} {f(t)}
>>>>
>>>> //allows calls like f(2);f(7);f(9);f(7);f(2); f(4); f(5);
>>>
>>> This is still just a form of:
>>>
>>> for x in tab {}
>>>
>>> For example:
>>>
>>> for x in (2,7,9,7,2,4,5) {f(x)}
>>>
>>> But this is more high-level. Just look at some other languages; it's
>>> all been done!
>>>
>>>
>>
>> its obviously not becouse you dont put those for in loops in places
>>
>> tab[^{1,3,7,9}] = 'corner';
>>
>> did they do
>>
>> tab[for x in {1,3,7,9}] = 'corner';
>>
>> thet would looks weird..there are abstract differencies in some cyntax
>> idea which are not the same as shallow syntax comparisons
>>
>> in fact it shows shortcut may be eventually used also
>>
>>
>> tab[1,3,7,9] = 'corner';
>>
>> but thats static case
>>
>>
>> t[] = {1,7,9,3}
>>
>> tab[t] = 'corner'
>>
>> could also be used
>>
>> so in fact indeed some ^ seem not mandatory
>>
>>
> note becouse this is important to realize:
>
> is some has some deeper "behind a syntax" observations
> then aspects of those abservations may open som enew pathes in code
> thinking tha just shallowly comparing syntaxes (and not realizing the
> "behind" side dfferences which are kinda invisible (untill youre very
> good in all that, bein able to catch and compare this invisible "behind"
> side ideas)
>
> you may say X looks like other X (ehere X is piece of some syntax) - it
> looks very close or it even may just look the same
>
> if thhere are other ideas on "behind" sides of one X and other X
> they are not he same - especially if one X with its behind ideas opens
> some new syntax gates/corridors/pathes for things
>
>
> right now after those combinations/considerations it seems:
>
>
> to get a loop in c you must
>
> "multiply or power" given block of code with "range or list"
>
> (as i said its rather power but is kinda abstract power so i some way
> one could also say its abstract operation of multiply, and in common
> language if some has
>
> "block" X "range"
> "block" X "list"
>
> some can say imo multiply some can say "power to" depending what is more
> convenient (i the context of those sentence multiply fits, normally imo
> power more fits, but both somewhat fits)
>
>
> so
>
> tab[2..88] this is a loop (as tab is multipied by range or powered by
> range)
>
> tab[t] -if t is array - is also a loop (of size of length of t)
>
> tab[2,36,7,3,2,4,5] - is aloso a loop (t turns)
>
> tab[i] would be loop if i is scope/range, if i is sole value its not a loop
>
> so ine can evenylually say that if i is value say 100 some can use ^ to
> turn it into scope/range
>
> int i = 0..100;
> tab[i]=0; //loop (101 turns)
>
> int i=100;
> tab[i] = 0;// not loop
>
> tab[^i] ; //loop (100 turns)
>
> all that abstract powering ideas lead to that
>
>
so it by incident maybe lead also to this conlusion
int A = 10;
A {printf("*");} //not a loop.. dont know what it is but not a loop
int t={2,4,5};
t {printf("%d", t);} //eventually a loop (no ^ needed though it may be
handy imo)
though this above is not needed if
printf("%d", t); //may be a loop if t is list
if so there is also a need to mke difference where printf takes a
"spacial" ram list and when it takes "temporal" cascade
printf("%d", ^t);
this can be used for temporal cascade but strictly it may not always be
needed..other form of distinguish here may play
so in fuct such
any expresion containing t - if t is this temporal cascade (scope or
list ) may be a loop
char* a = "ssdd";
char* b= "SDDSDSD"
a=b;
may be a loop
only need to say a or b is temporal cascade (more on this later)
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2026-11-10 16:38 +0100 |
| Message-ID | <11cvdq3$2908n$1@dont-email.me> |
| In reply to | #404202 |
yet to sey its cklearrer (as i know my "chain of reasoning" may be hard
to folow)..some pieces i can explain with no context so its easy to gat
say
int a[] = {2,4,5,6,5,33,223,445,5};
it is "spatial" array (i mean sequence of ints in ram?
or it is "temporal cascade"
it MAY be both so it probbaly has not much sence to denote this
spatial int a[] = {2,4,5,6,5,33,223,445,5};
temporal int a[] = {2,4,5,6,5,33,223,445,5};
becouse compilar anyway cant probably hold this temporal list other way
than in ram (sometimes it may eventually discard it but im not sure if
noting it as a temporal is veru sefull)
so
int a[] = {2,4,5,6,5,33,223,445,5};
is both "spacial ram array" and "temporal cascde"
the using it as spacial array would just pass a pointer to it
like passing to foo(a) where foo waits for int*
passing it to tab[a] = something just calls a temporal cascade
of calls (which is loop)
the question is where with context you may know its spatial and when you
know when its temporat and if some contextes it can be both make some
syntax to point put shich one it may be
scopes/ranges ike 5..10 also may be used for temporal cascases
(though they also may be used for spacial arrays)
IN fact it shows (this chain of reasoning shows) in C you may realize
for loops just by throwing temporal cascades in code (various ways)
[toc] | [prev] | [next] | [standalone]
Page 4 of 5 — ← Prev page 1 2 3 [4] 5 Next page →
Back to top | Article view | comp.lang.c
csiph-web