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

Liste des GroupesRevenir à cl c 
Sujet : Re: Loops (was Re: do { quit; } else { })
De : janis_papanagnou+ng (at) *nospam* hotmail.com (Janis Papanagnou)
Groupes : comp.lang.c
Date : 15. Apr 2025, 08:17:24
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vtl166$36p6b$1@dont-email.me>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
User-Agent : Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
On 14.04.2025 17:22, bart wrote:
On 14/04/2025 13:18, Janis Papanagnou wrote:
(While there's some "C" stuff in here it contains a lot of non-"C"
samples for comparison. So [OT]-sensible folks may want to skip this
post.)
 
[...]
 
I'm not saying there's anything wrong with it. The point was that an A
to B loop existed in the 1950s; C came out in the 1970s!
 
[...]
[...]
 
which of course would be written with a 'while'
>
   int i = a;
   while (i <= b) f(i++)
 
That would be a poor use of 'while'.

Not the least.

And bizarre, to use 'while' for
iteration, but 'for' for loops that are best written as while!

I was merely trying to provide some options to address your dislike.

 
The "C" syntax has actually a flexibility that is very valuable.
 
The flexibility is the problem, because you have to specify the loop in
such excruciating detail. It is easy to make a mistake which results in
still legal code. And you now have to analyse each loop to see what kind
of loop it is:

Well, our opinions obviously differ. I just give you two examples
(and there's many variants of these) of not uncommon 'for' usages...

    for (c=0; bitstr; c++)
        bitstr &= bitstr-1;

    for (r=1; r<=0x80; r<<=1)
        ...

and someone already posted another iteration type on linked lists

    for (node = list; node; node = node->next)

The point here is the observation that there are loops that deviate
from simple counted loops (and that are commonly used) and that they
all comprise the same principal structure; initialization, condition
test, change of loop-variables. The "C" loop syntax reflects that in
its typical low-level syntax form. (I already said that personally I
don't like "C"'s syntax, but I do like its flexibility.)

[...]
 
Suppose you see 'i <= N' as the condition; is that '<=' intentional, or
is it a typo for '<'? It's impossible to tell.

(This is nonsense.)

 
You can also say that a combination of labels, gotos and 'if' is even
more flexible! But C is supposed to be a HLL.

Actually, "C" is (IMO) not as high-level as some other languages are.
I always considered it (snippy) as a excellent "assembler". So if I
judge "C"'s constructs I do so on the abstraction level the designers
have chosen. (Or at least I try to do that.)

(It's nonsense to make up an "argument" for 'goto'.)

[...]
>
They don't need to be identical, because you can write many more
types of loops than simple counted loops. - This is actually an
advantage;
 
This is the kind of error I was making all the time (writing the first
line, copying it, but forgetting to convert all the variables):
 
   for(i=0; i < M; ++i)
      for(j=0; j < N; ++i)

That first of all means that you are obviously a sloppy programmer.

Especially if you are doing that "all the time" it's something you
should work on. (And I don't mean, by writing yet another personal
programming language that suits you better.)

(There's something I've heard about in the 1990's, "PSP", "Personal
Software Process"[*], that might help you increase your success rate
by reducing common errors you make.)

[*] https://en.wikipedia.org/wiki/Personal_software_process

 
Here, it is not an advantage. I once asked David Brown how many of his
for-loops were simple iteration; I think he said 98.5%.

This number, I think, may be close to reality. - I want to remind
that N. Wirth gave such informal statistics as rationale for Pascal
only supporting for-loops with increment and decrement values of 1.

But given the flexibility of "C"'s syntax that statistics certainly
has changed; with "C" you can formulate sensible 'for' loops that
were just not possible [within the 'for'-syntax] before. (I gave
[just a few] example above; there's yet more.) Now that you can
formulate such loops their number increased as far as I observe.

 
In my case it would be nearer 100%. It's amazing, with the amount of
lower-level coding I do, how little I need to use the flexibility of C's
'for'.

I'm not too astonished; programming is also based on many personal
factors.

 
Anything unusual can generally be achieved with minor workarounds.
 
However with linked-list traversal, that's an example that people gave
of how flexible for-loops can be:
 
    for (p = head; p; p = p->next)
 
I suggested that could have been better done with an extension to
'while'. I made a proof-of-concept in my language:
 
     p := head
     while p, p:=p.next do
 
This feature I've kept.

Now that is strange. - Before[*] you argued on a 'while' example:

  "That would be a poor use of 'while'. And bizarre, to use
   'while' for iteration, but 'for' for loops that are best
   written as while!"

Your mindset on that seems to not yet have reached a stable state.

But back to the topic; why do you think that introducing yet another
new syntax would be sensible or even more useful than just using an
already existing (and fitting) one; because you don't like it that
way?

[*] I had snipped it in this post because it appeared to me so
nonsensical, but if I knew that you support that... - Anyway.

 
it allows a lot more sensible loop code patterns than>
those other primitive loops! - I'm astonished that your code
pattern repertoire is so limited. (Or that you are arguing again
just to contribute anything, however stupid that is.)
 
It sounds like you're being insulting again just to keep your hand in.
Why is it some people just cannot resist getting personal?

There's a few properties that you have problems with that lie not
within the language but are inherent part of your personality. -
You clearly exposed two of them; above your problem of handling
your copy/paste programming errors ("PSP") and here that you are
restricted in your self-imposed cage of not detecting (and also
not understanding, if told) that there's many more that you don't
perceive and that it's used to advantage.

 
>
* C needs you to specify how to increment the loop index
>
Of course; another advantage! (And this is common in many
programming languages, older and newer ones.)
 
You need to tell the computer how to count? OK!

Yes. - Either  i++  or  i+=2  or  z*=10  or  r<<=4  or  ...

You say OK but you don't see the obvious applications, do you?
Meanwhile?

 
* Fortran allows an arbitrary number of statements in the loop body.
   C allows only one; multiple statements require a compound statement.
>
Jesus! - At times I see you as a sensible communication partner,
but in this sub-thread I've no hope. - I'll finish this post and
stop responding to such stupid posts of yours...
 
I don't understand; what exactly is the problem here [...]

There's languages (like Algol 68, Eiffel, Unix Shell, etc.)
where you have "closed" control constructs (if-fi, do-done,
case-esac) which make it unnecessary to introduce blocks or
compound statements in their context. In other languages
(Pascal, Simula, "C", etc.) you don't have that and if you
want to have multiple statements in a control structure you
naturally need to syntactically comprise them.

That doesn't make the crude and limited Fortran 'for' loop
any better only because it has a "100 continue" or "end do".

In C you have do this:

[ snip bart's known problems with compound statement blocks ]

(I suggest, here as well, to make yourself familiar with the
above mentioned "PSP" methods if you have difficulties with
program evolution and compound statements.)

 
If I understand you, you think it is idiotic for me to bring up what you
clearly perceive as a non-problem?

(I see you have a problem that only you can fix.)

 
Even though it is one that also existed in Algol60 and Pascal, and was
solved by Algol68, and now is common in many languages that don't use
braces. (Braces are the equivalent of BEGIN-END.)

Having "closed" control constructs (i.e. making explicit braces
unnecessary) is IMO a Very Good Thing; and personally I prefer
languages that support such syntaxes. "C" is not such a language.

Having end-tags doesn't make Fortran a good language or its 'do'
loop a good syntax.

 
(Huh? You have issues with keywords in caps?
 
Yes I have issues with *constantly* switch from lower case all-caps. It
is tedious, error prone and the result is ugly code.

Okay.

 
That doesn't bother you? [...]

I'm no typist, I have no typist's education, but with my decades
practice in programming I type sufficiently fast and have indeed
no problem to occasionally put my small finger on the Shift key
as professional typists do. - No that doesn't bother me.

(Things that bother me w.r.t. typing are that the braces that are
typical of "C" and used there in masses are on my non-US keyboard
quite difficult to reach.)

But
again, notice that most languages these days do not distinguish reserved
words like that.

Yes. And I'm fine with that. Especially since I'm using editors
with syntax highlighting and nowadays don't print source code
in black and white on paper any more. For plain text posts it's
still an advantage, though, to have the keywords stand out. And
despite the highlighting in my editor it also adds to readability
when writing and reading programs.

 
There were various stropping methods used in the past, some
better some worse. The Genie compiler-interpreter uses all caps
and it looks great; makes the keywords stand out and makes the
code structure very clear and perfectly legible! (YMMV.)
>
And you have a powerful, yet minimalistic syntax; you "pay"
only for what you need and can express anything. Examples...
>
[ snip Algol 68 examples ]
 
(Note: Algol68 comments need a trailing # too.)

Yes, I know. I added that '#' for posting only. (Despite '#' is
[pairwise] usable in the Genie context I'm nonetheless using
the classical and portable  CO ... CO  in my programs instead.)

 
[ snip some bart language specific features ]
 
* I don't have embedded WHILE, instead I have embedded WHEN, which
affects only that iteration. (WHILE will stop the loop when false. Note
that Algol68 did not have 'break'; it has to use 'goto'.)

Yes, Algol 68 (as so many languages back these days) has 'goto'
available, and used with labels (as opposed to line numbers).

(You don't need 'break' or 'goto' to leave loops, especially if
the language supports [also as part of a 'for' loop] 'while'.)

But what are you trying to say here?

[ snip more bart language specific features ]
 
However, I'm not sure why we're talking about Algol68:

(Oh, right, and obviously also about your language/preferences.)

my complaint was
about why some languages chose to copy C's crude for-loop syntax,

You mixed into the discussion _your_ compound statement issue
[that Algol 68 addresses]. You said your language addresses some
of the issues you have with "C"'s syntax, where you did not a
job as good as Algol 68 did. You could not see, less appreciate
the flexibility of "C"'s 'for' loop syntax design decision.

but it it was considered primitive even in 1972.

The whole "C" language is "primitive" (in some respects) if
compared to other HLLs.

[...]
 
* all loop-parts (but DO and OD) optional; no typing
   overhead, clear constructs, sensible defaults for
   omitted parts
 
I have sensible defaults too! I also don't have annoying rules about
semicolons,

(Yes, I know that you have noticeable problems where others don't
care much. You repeatedly told and reminded us about that. Okay.)

or problems with empty bodies:
 
   DO SKIP OD

If there'd be an 'empty statement' possible to have in Algol 68
(so that I could omit the 'SKIP' in your example) I'd likely have
nonetheless added a comment to indicate the deliberate absence of
a statement. (I use such defensive programming patterns with comments
also in other languages.) YMMV, but I think it's useful if people
work together in projects, but also if one is programming just for
own fun.

Where you think a terse  DO OD  is best others might prefer to see
it documented  DO # nothing to do # OD  and are delighted if that
"comment" is even standardized by a clear 'NOP' as in  DO SKIP OD .

[...]
 
 
The Simula loop, while not as rich as Algol 68's, has
also some distinct specifics; just a short example
>
   FOR z := 2, 3, 5, 7, 11, 13, 17, 19,
            21 STEP 2 UNTIL 99,
            z+1 WHILE p(z)  DO   ...
 
What is it demonstrating?

That there are a couple _different_ ways that language designers
can address loop semantics and supported loop features. All the
three languages have differing approaches, and all with sensible
rationales.

Since it seems to be merely this:
 
  for z in X while p(z) DO

No. As opposed to Algol 68 the Simula 'while' condition is bound
[in the example above] to the "z+1" part of the 'for' expression.

[...]
 
And you think Fortran's loop is a good paragon? *sigh*
 
It seems we could have kept this short.
 
I said that Fortran's original DO-loop was more advanced than C's for-loop.
 
You are saying that because there exist languages with more
sophisticated loops, that that somehow excuses C's poor effort?

No.

I was saying that there are different approaches in different
languages, and that there are good reasons why these languages
(Algol 68, Simula, Pascal, "C") have defined it in their way;
you can do useful things in very flexible (and clear) ways.
(And that Fortran is IMO not amongst those languages. - YMMV.)

(I also hinted about some other things, your issues and "your
language", how you "solved" those "issues", that are not worth
expanding on.)

Janis


Date Sujet#  Auteur
4 Apr 25 * do { quit; } else { }625Thiago Adams
4 Apr 25 +* Re: do { quit; } else { }2bart
4 Apr 25 i`- Re: do { quit; } else { }1Thiago Adams
4 Apr 25 +* Re: do { quit; } else { }11Kaz Kylheku
4 Apr 25 i+* Re: do { quit; } else { }3Thiago Adams
4 Apr 25 ii`* Re: do { quit; } else { }2Kaz Kylheku
4 Apr 25 ii `- Re: do { quit; } else { }1Chris M. Thomasson
4 Apr 25 i+* Re: do { quit; } else { }4Kaz Kylheku
4 Apr 25 ii+* Re: do { quit; } else { }2Thiago Adams
4 Apr 25 iii`- Re: do { quit; } else { }1Thiago Adams
8 Apr 25 ii`- Re: do { quit; } else { }1candycanearter07
5 Apr 25 i`* Re: do { quit; } else { }3Janis Papanagnou
5 Apr 25 i +- Re: do { quit; } else { }1Janis Papanagnou
6 Apr 25 i `- Re: do { quit; } else { }1Michael S
4 Apr 25 +* Re: do { quit; } else { }608Tim Rentsch
4 Apr 25 i`* Re: do { quit; } else { }607Thiago Adams
6 Apr 25 i +* Re: do { quit; } else { }600Tim Rentsch
6 Apr 25 i i+* Re: do { quit; } else { }550Michael S
6 Apr 25 i ii`* Re: do { quit; } else { }549Tim Rentsch
6 Apr 25 i ii `* Re: do { quit; } else { }548Michael S
7 Apr 25 i ii  `* Re: do { quit; } else { }547Tim Rentsch
7 Apr 25 i ii   `* Re: do { quit; } else { }546Michael S
7 Apr 25 i ii    +* Re: do { quit; } else { }542bart
8 Apr 25 i ii    i`* Re: do { quit; } else { }541David Brown
8 Apr 25 i ii    i `* Re: do { quit; } else { }540bart
8 Apr 25 i ii    i  +* Re: do { quit; } else { }535David Brown
8 Apr 25 i ii    i  i`* Re: do { quit; } else { }534bart
8 Apr 25 i ii    i  i +* Re: do { quit; } else { }78Tim Rentsch
8 Apr 25 i ii    i  i i`* Re: do { quit; } else { }77bart
8 Apr 25 i ii    i  i i +* Re: do { quit; } else { }74Tim Rentsch
8 Apr 25 i ii    i  i i i`* Re: do { quit; } else { }73bart
9 Apr 25 i ii    i  i i i `* Re: do { quit; } else { }72Tim Rentsch
9 Apr 25 i ii    i  i i i  `* Re: do { quit; } else { }71bart
9 Apr 25 i ii    i  i i i   +- Re: do { quit; } else { }1Chris M. Thomasson
9 Apr 25 i ii    i  i i i   +- Re: do { quit; } else { }1Chris M. Thomasson
9 Apr 25 i ii    i  i i i   `* Re: do { quit; } else { }68Tim Rentsch
10 Apr 25 i ii    i  i i i    +* Re: do { quit; } else { }63bart
10 Apr 25 i ii    i  i i i    i+* Re: do { quit; } else { }61Kaz Kylheku
10 Apr 25 i ii    i  i i i    ii+* Re: do { quit; } else { }2Michael S
10 Apr 25 i ii    i  i i i    iii`- Re: do { quit; } else { }1Kaz Kylheku
10 Apr 25 i ii    i  i i i    ii`* Re: do { quit; } else { }58bart
10 Apr 25 i ii    i  i i i    ii +* Re: do { quit; } else { }43Keith Thompson
10 Apr 25 i ii    i  i i i    ii i+* Re: do { quit; } else { }39bart
10 Apr 25 i ii    i  i i i    ii ii+* Re: Endless complaints [was Re: do { quit; } else { }]16bart
10 Apr 25 i ii    i  i i i    ii iii+* Re: Endless complaints [was Re: do { quit; } else { }]14Janis Papanagnou
11 Apr 25 i ii    i  i i i    ii iiii`* Re: Endless complaints [was Re: do { quit; } else { }]13bart
11 Apr 25 i ii    i  i i i    ii iiii +- Re: Endless complaints [was Re: do { quit; } else { }]1Keith Thompson
11 Apr 25 i ii    i  i i i    ii iiii +- Re: Endless complaints [was Re: do { quit; } else { }]1Kaz Kylheku
11 Apr 25 i ii    i  i i i    ii iiii `* Re: Endless complaints [was Re: do { quit; } else { }]10David Brown
11 Apr 25 i ii    i  i i i    ii iiii  `* Re: Endless complaints [was Re: do { quit; } else { }]9bart
11 Apr 25 i ii    i  i i i    ii iiii   +* Re: Endless complaints [was Re: do { quit; } else { }]5Michael S
11 Apr 25 i ii    i  i i i    ii iiii   i`* Re: Endless complaints [was Re: do { quit; } else { }]4bart
11 Apr 25 i ii    i  i i i    ii iiii   i `* Re: Endless complaints [was Re: do { quit; } else { }]3Michael S
11 Apr 25 i ii    i  i i i    ii iiii   i  +- Re: Endless complaints [was Re: do { quit; } else { }]1Janis Papanagnou
11 Apr 25 i ii    i  i i i    ii iiii   i  `- Re: Endless complaints [was Re: do { quit; } else { }]1bart
11 Apr 25 i ii    i  i i i    ii iiii   +- Re: Endless complaints [was Re: do { quit; } else { }]1David Brown
11 Apr 25 i ii    i  i i i    ii iiii   +- Re: Endless complaints1Tim Rentsch
11 Apr 25 i ii    i  i i i    ii iiii   `- Re: Endless complaints [was Re: do { quit; } else { }]1Keith Thompson
10 Apr 25 i ii    i  i i i    ii iii`- Re: Endless complaints [was Re: do { quit; } else { }]1Keith Thompson
10 Apr 25 i ii    i  i i i    ii ii`* Re: do { quit; } else { }22Keith Thompson
11 Apr 25 i ii    i  i i i    ii ii `* Re: do { quit; } else { }21bart
11 Apr 25 i ii    i  i i i    ii ii  `* Re: do { quit; } else { }20Keith Thompson
11 Apr 25 i ii    i  i i i    ii ii   `* Re: do { quit; } else { }19Michael S
11 Apr 25 i ii    i  i i i    ii ii    +- Re: do { quit; } else { }1David Brown
11 Apr 25 i ii    i  i i i    ii ii    +* Re: do { quit; } else { }16Kaz Kylheku
11 Apr 25 i ii    i  i i i    ii ii    i+* Re: do { quit; } else { }2bart
11 Apr 25 i ii    i  i i i    ii ii    ii`- Re: do { quit; } else { }1Keith Thompson
13 Apr 25 i ii    i  i i i    ii ii    i`* Re: do { quit; } else { }13Michael S
12 May 25 i ii    i  i i i    ii ii    i `* Re: do { quit; } else { }12Tim Rentsch
12 May 25 i ii    i  i i i    ii ii    i  `* Re: do { quit; } else { }11David Brown
12 May 25 i ii    i  i i i    ii ii    i   `* Re: do { quit; } else { }10Keith Thompson
13 May 25 i ii    i  i i i    ii ii    i    `* Re: do { quit; } else { }9David Brown
14 May 25 i ii    i  i i i    ii ii    i     `* Re: do { quit; } else { }8James Kuyper
14 May 25 i ii    i  i i i    ii ii    i      +* Re: do { quit; } else { }6Keith Thompson
14 May 25 i ii    i  i i i    ii ii    i      i+* Re: do { quit; } else { }4James Kuyper
14 May 25 i ii    i  i i i    ii ii    i      ii`* Re: do { quit; } else { }3David Brown
14 May 25 i ii    i  i i i    ii ii    i      ii +- Re: do { quit; } else { }1Kaz Kylheku
15 May 25 i ii    i  i i i    ii ii    i      ii `- Re: do { quit; } else { }1James Kuyper
14 May 25 i ii    i  i i i    ii ii    i      i`- Re: do { quit; } else { }1David Brown
14 May 25 i ii    i  i i i    ii ii    i      `- Re: do { quit; } else { }1Tim Rentsch
11 Apr 25 i ii    i  i i i    ii ii    `- Re: do { quit; } else { }1Keith Thompson
6 May 25 i ii    i  i i i    ii i`* Re: do { quit; } else { }3Tim Rentsch
6 May 25 i ii    i  i i i    ii i `* Re: do { quit; } else { }2Keith Thompson
6 May 25 i ii    i  i i i    ii i  `- Re: do { quit; } else { }1Tim Rentsch
10 Apr 25 i ii    i  i i i    ii `* Re: do { quit; } else { }14Kaz Kylheku
10 Apr 25 i ii    i  i i i    ii  +* Re: do { quit; } else { }11bart
10 Apr 25 i ii    i  i i i    ii  i+* Re: do { quit; } else { }2Kaz Kylheku
11 Apr 25 i ii    i  i i i    ii  ii`- Re: do { quit; } else { }1bart
11 Apr 25 i ii    i  i i i    ii  i+* Re: do { quit; } else { }6Tim Rentsch
11 Apr 25 i ii    i  i i i    ii  ii`* Re: do { quit; } else { }5Keith Thompson
11 Apr 25 i ii    i  i i i    ii  ii `* Re: do { quit; } else { }4Tim Rentsch
11 Apr 25 i ii    i  i i i    ii  ii  `* Re: do { quit; } else { }3Keith Thompson
11 Apr 25 i ii    i  i i i    ii  ii   +- Re: do { quit; } else { }1bart
5 May 25 i ii    i  i i i    ii  ii   `- Re: do { quit; } else { }1Tim Rentsch
11 Apr 25 i ii    i  i i i    ii  i+- Re: do { quit; } else { }1Keith Thompson
11 Apr 25 i ii    i  i i i    ii  i`- Re: do { quit; } else { }1Keith Thompson
10 Apr 25 i ii    i  i i i    ii  +- Re: do { quit; } else { }1bart
10 Apr 25 i ii    i  i i i    ii  `- Re: do { quit; } else { }1Kaz Kylheku
11 Apr 25 i ii    i  i i i    i`- Re: do { quit; } else { }1Tim Rentsch
9 May 25 i ii    i  i i i    `* Re: do { quit; } else { }4Bonita Montero
9 May 25 i ii    i  i i i     `* Re: do { quit; } else { }3Richard Heathfield
9 Apr 25 i ii    i  i i +- Re: do { quit; } else { }1Richard Damon
9 Apr 25 i ii    i  i i `- Re: do { quit; } else { }1David Brown
9 Apr 25 i ii    i  i `* Re: do { quit; } else { }455David Brown
8 Apr 25 i ii    i  +- Re: do { quit; } else { }1Tim Rentsch
9 Apr 25 i ii    i  `* Re: do { quit; } else { }3Ike Naar
8 Apr 25 i ii    `* Re: do { quit; } else { }3Tim Rentsch
6 Apr 25 i i`* Re: do { quit; } else { }49Michael S
7 May 25 i `* Re: do { quit; } else { }6Wuns Haerst
6 Apr 25 +- Re: do { quit; } else { }1Lawrence D'Oliveiro
6 Apr 25 +- Re: do { quit; } else { }1David Brown
18 Apr 25 `- Re: do { quit; } else { }1Mikko

Haut de la page

Les messages affichés proviennent d'usenet.

NewsPortal