Sujet : Re: Loops (was Re: do { quit; } else { })
De : 643-408-1753 (at) *nospam* kylheku.com (Kaz Kylheku)
Groupes : comp.lang.cDate : 17. Apr 2025, 00:49:22
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <20250416164536.110@kylheku.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
User-Agent : slrn/pre1.0.4-9 (Linux)
On 2025-04-16, bart <
bc@freeuk.com> wrote:
On 16/04/2025 22:43, Kaz Kylheku wrote:
On 2025-04-16, bart <bc@freeuk.com> wrote:
On 16/04/2025 06:35, Janis Papanagnou wrote:
On 15.04.2025 22:46, bart wrote:
On 15/04/2025 20:07, Scott Lurndal wrote:
[...]
Real for loops _are_ a three-way construct.
>
[...]
>
Any step other than 1 is unusual. [...]
>
Nonsense. Arithmetic loop steps other than one are noting unusual
and been supported by programming languages (and also been used)
since decades in programming.
>
So what are you claiming, that the majority of loops in any given
program will have steps other than +1 or -1?
Hey Bart, how would you handle a loop like
do x = m to n ...
where m and n are not known until run time, and may be the
extreme values of the type? Like C's INT_MIN and INT_MAX, respectively,
where x is of type int.
Because in this loop, x takes on every possible value of the type,
we cannot have a loop guard which prevents entry of the loop body
based on solely the value of x.
>
I'm not exactly sure what you are asking. Is it a loop like this, here
in my language:
>
int n:=0
>
for i in i32.bounds do # ie. i32.min .. i32.max
++n
od
>
println n
>
This works fine; after a second or so it displays 4294967296.
>
However, this languages evaluates using 64 bits. Perhaps this loop may
demonstrate the issues better:
>
for i in i64.bounds do
>
However, I would estimate it would take 190 years to finish.
Sure, but you could have a loop that goes over the last n
values of the range of i64, for a reasonably small n.
I assume you're thinking of C which uses i32 and where comparisons near
the extreme values of the type are problemetical. Or this line in my
Comparisons aren't; gratuitous increments or displacements are.
language:
>
for i in i64.max-10 .. i64.max do println i
Exactly, small n.
which doesn't stop (u64 is OK however).
What? That's a boogy bug.
That doesn't worry me too much,
I can just add a Note to the language spec warning of UB when a for-loop
bound is at the limits of the type.
I will frame these words next time you cricize C of taking some
easy way out and shirking doing the Right Thing with UB.
Where all sorts of other stuff can
happen because of how values wrap.
You can fix all the other stuff at the language level also.
Then we can do
for (int i = INT_MIN; : i < INT_MAX; i++)
After the last iteration, i is INT_MAX, and so the test fails.
The loop terminates without performing i++.
>
You're trying too hard. I don't think the language needs to bother
providing solutions, it just needs to specify the limitations.
I don't understand why you're not in the C camp with these words.
-- TXR Programming Language: http://nongnu.org/txrCygnal: Cygwin Native Application Library: http://kylheku.com/cygnalMastodon: @Kazinator@mstdn.ca
do { quit; } else { }
Re: do { quit; } else { }