Is http://sprunge.us/MOJIg4 a legitimate use of a for loop with break? I know there are better ways to do it, but I'm just wondering whether it's legitimate.

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm

What are you trying to do exactly? It's an array with a terminator string? Probably the length of the array should be set instead of doing string compares every loop.

program fordo;
var words: array[1..6] of string;
var ss: integer;
begin
for ss := 1 to 6 do
   words[ss] := '~';
words[1] := 'One';
words[2] := 'Two';
words[3] := 'Three';
for ss := 1 to 6 do
   if words[ss] = '~' then
      break
   else
      write(words[ss], '    ');
writeln;
end.

Regards,
Ryan Joseph

Hairy Pixels via fpc-pascal said on Fri, 16 Jun 2023 09:57:36 +0700

Explore FPC.

It's an array with a terminator string? Probably the length of the array should be set instead of doing string compares every loop.

I need to set it in the var declaration, right?

^^^^^^^^^^^^^^^^^^^^ Is it legitimate to set elements inside a for loop?

^^^^^ IS IT legitimate to use a break (or continue) inside a for loop?

Thanks,

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm

I'm certainly not the expert in FPC's details, so maybe there'll you'll get a better answer. I just tell you my point of view.

I don't quite understand this question, but of it's about the length of the array, there are two ways:

a) Statically as "VAR x: array[1..6] of string"
b) Dynamically:

var x: array of string;  // I prefer x: TStringArray instead, but this requires the classes unit IIRC
begin
  SetLength(x, 6); // will always declare a zero-based index, i.e. x[0]..x[5]
  // the advantage is you can change this lateron:
  SetLength(x, 7); // keeps items 0..5 and adds x[6]
end;

words[ss] := '~'; ^^^^^^^^^^^^^^^^^^^^ Is it legitimate to set elements inside a for loop?

Yes, of course. You're not allow to change the loop variable, but you can assign array values there without any problem. In fact, with larger arrays, it may even be the *only* way to do it. (Except using a different loop type like while or repeat, of course.)

Imagine you want to have x^2 for x = 0...1000:

var y: array[0..1000] of integer; x: integer;
begin
  for x:=0 to 1000 do  // ; I prefer: for x := Low(y) to High(y) do
  y[x] := x * x;
end;

If you couldn't do that, you'd have to write

y[0] := 0;
y[1] := 1;
y[2] := 4;
y[3] := 9;
....

if words[ss] = '~' then break ^^^^^ IS IT legitimate to use a break (or continue) inside a for loop?

As far as I know, there are different opinions about this. The clear answer to whether it's *legitimate* is YES, because that's what "break" is meant for.

Whether it's elegant is a different question. In my opinion YES because it often gives better readable code than nested "if" statements inside the loop. But I've also read that using "break" is discouraged because it shows a bad choice of the loop range.

Kind regards,
Thomas

On Jun 16, 2023, at 6:23 PM, Thomas Kurz via fpc-pascal wrote: Whether it's elegant is a different question. In my opinion YES because it often gives better readable code than nested "if" statements inside the loop. But I've also read that using "break" is discouraged because it shows a bad choice of the loop range.

This is highly suspect. Doing an early break in loops is the essence of how to do linear searching. No idea who thinks that's a bad idea.

Regards,
Ryan Joseph

20 years ago there were some programmers, claiming a loop condition must only be at start or end, but not in the middle.

Gladfully, most programmers came to their senses.

Mattias

This is interesting, because it's the first time I've ever seen "break" as a valid command in pascal, and I've been using pascal since the mid/late 80s.  All kinds of dialects too, and I've never seen break as a keyword.  C, Python, Perl, sure, even shell scripts, but pascal? Never seen it used before.  Is this a relatively new addition to fpc or something?

Le 17/06/2023 à 20:07, Travis Siegel via fpc-pascal a écrit :

Is this a relatively new addition to fpc or something?

I 've just found it in my Delphi 7 code (and code very likely written for Delphi 4), so I think it's there since at least 2000-2001 ...

May be it appeared with Delphi 1 ?

I've been using break very often in Pascal loops for 25 years since Delphi 2. Also continue.

My code is littered with:

repeat
  do_something;
  if x then BREAK;
  if y then CONTINUE;
  do_something_else;
  Application.ProcessMessages;
  if key_clicked then EXIT;
until 00;

ProcessMessages allows the user to stop the loop if it is running out of control.

Martin.

I believe it was added in TP/BP7.

Tomas

On Jun 18, 2023, at 1:07 AM, wrote: This is interesting, because it's the first time I've ever seen "break" as a valid command in pascal, and I've been using pascal since the mid/late 80s. All kinds of dialects too, and I've never seen break as a keyword. C, Python, Perl, sure, even shell scripts, but pascal? Never seen it used before. Is this a relatively new addition to fpc or something?

I don't remember break NOT being in Pascal. How did you exit a loop otherwise, goto? Break is common in basically all languages now. Can't think of a language I've used without it.

Regards,
Ryan Joseph

Obviously, loop is exited using the loop condition by default and that may be achieved without additional constructs, should it be break or goto. Yes, using break may be more elegant in certain cases, but that's another story.

Tomas

FWIW, when I started to work on New Stanford Pascal (http://bernd-oppolzer.de/job9.htm)
in 2011, the very first thing that I did was to add BREAK, CONTINUE and RETURN to this compiler.
New Stanford Pascal is an offspring of the Zürich P4 compiler from the 1970s, directly from
the working group of Niklaus Wirth (who was at Stanford, too, BTW).

The compiler is a self-hosting compiler (like most Pascal compilers, I believe) and up to 2011
there were many exits from loops bye putting a label after the loop and using GOTO
(because of the absence of BREAK). Similar use of GOTO to implement CONTINUE and RETURN.

I got rid of most of these labels (if not all) by adding these three keywords. This was easy.
I did many extensions to the compiler later (from 2016 on) and ported the compiler to Windows and
Linux etc.; the compiler, which had 6.000 lines in 2011, now has over 25.000 lines :-)

Kind regards

Bernd

Regards, Ryan Joseph

the Break keyword first appeared in Turob/Borland Pascal 7.0 along with the Continue keyword... to refresh my memory, i searched the various reference manuals for TP/BP versions... the first one that did not have "break" as part of CheckBreak, CBreak, and similar was TP/BP 7.0...

http://bitsavers.informatik.uni-stuttgart.de/pdf/borland/turbo_pascal/Turbo_Pascal_Version_7.0_Language_Guide_1992.pdf

page 86:

If the number of repetitions is known beforehand, the for statement is the appropriate construct. Otherwise, the while or repeat statement should be used.

The Break and Continue standard procedures can be used to control the flow of repetitive statements: Break terminates a repetitive statement, and Continue continues with the next iteration of a repetitive statement. For more details on these standard procedures, see Chapter I, "Library reference," in the Programmer's Reference.

http://www.bitsavers.org/pdf/borland/turbo_pascal/Turbo_Pascal_Version_7.0_Programmers_Reference_1992.pdf

page 15:

Break procedure System ------------------------------------------------------------------------- Purpose Terminates a for, while, or repeat statement.

    Declaration   procedure Break;
        Remarks   Break exits the innermost enclosing for, while, or repeat
                  statement immediately. Break is analogous to a goto statement
                  addressing a label just after the end of the innermost
                  enclosing repetitive statement. The compiler reports an error
                  if Break is not enclosed by a for, while, or repeat statement.
       See also   Continue, Exit, Halt
        Example
                  var S: string;
                  begin
                    while True do
                    begin
                      Readln(S);
                      if S = '' then Break;
                      Writeln(S);
                    end;
                  end.

Hairy Pixels wrote

I don't remember break NOT being in Pascal. How did you exit a loop otherwise, goto? Break is common in basically all languages now. Can't think of a language I've used without it.

Use a variable, set the variable when you hit an exit criteria, then before repeating the loop, check the variable, if it's true, exit the loop (exit does this), or just craft the loop (easy to do if it's a loop until construct) so it exits the loop automatically.  Probably not as efficient as break, but since I didn't know it was a valid command, <shrug>

Heh, interesting enough, I've never used goto in a pascal program either, but at least I was aware that keyword existed. :)

It's taken some work at times *not* to use goto, but I learned goto was a bad thing when I was first learning to code, way back in the mid 80s, so I've never used it except in basic code, where it's often impossible to avoid, with the way code is written.

“Exit” leaves the surrounding *function*, not the surrounding *loop*.

Regards,
Sven

Hairy Pixels via fpc-pascal said on Sun, 18 Jun 2023 08:04:23 +0700

When I learned Pascal at Santa Monica Community College (SMC), the professors repeatedly hammered home that a loop should have exactly one entry point and one exit point. You don't exit until your test condition goes false, and then you go down to the bottom of the loop body and don't iterate further.. No matter how many levels of if statements you had to use, you weren't supposed to use anything like break, continue or exit in the loop. I don't remember whether those keywords actually existed then.

I can still make a good argument for what my professors taught me, but in the intervening years, I found break and especially continue wonderful for increasing readability.

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm

Educators continuously have stupid ideas that don't work out as intended in the real world. I would love to see them make a real program that does something difficult and not use early breaks.

I assume them they forbid early exits in functions also or is the loop special for them?

Regards,
Ryan Joseph

Il 20/06/2023 09:05, Hairy Pixels via fpc-pascal ha scritto:

Educators continuously have stupid ideas that don't work out as intended in the real world. I would love to see them make a real program that does something difficult and not use early breaks. I assume them they forbid early exits in functions also or is the loop special for them?

You don't need something difficult to show that avoiding break is stupid! Just take a loop searching a linked list for a specific item. You must test two conditions: item found or end of list. But the item you're searching might be the last one, so you can't test next=Nil at the beginning of a do-while loop. A repeat-until can't be used because the list might be empty.

I prefer in those cases use a function, and exit instead of break, so that the caller can easily test how the loop was terminated, but it's just a matter of tastes.

Giuliano

On Tue, 20 Jun 2023 14:05:04 +0700, Hairy Pixels via fpc-pascal declaimed
the following:

One-IN/One-OUT was a tenet of Structured Programming as used in the late 1970s/early 1980s -- and yes, it also applied to subprograms (functions and routines both for those languages that differentiated) and IF statements.

This is also about the same time that Chapin/Nassi-Schneiderman charts were developed to be used in place of free-form flow-charts. N-S chart elements enforced a one-in/one-out diagramming of the logic (no GOTO equivalent). If it required nesting IF statements to avoid ad-hoc GOTO, so be it. Mapping those structures to "unstructured" languages (COBOL 74, FORTRAN IV, BASIC, etc.) might require reverting to GOTO -- but an organization's programming standards guidelines would define exactly how a structured entity would be mapped, and could thereby be reviewed for compliance.

{structured}
if condition then
do stuff
else
do other stuff
endif

{FORTRAN IV}
if .not. (condition) then goto {elselabel}
do stuff
goto {endiflabel}
{elselabel} continue
do other stuff
{endiflabel} continue

[FORTRAN "CONTINUE" is a NOP statement, often used as the target of a GOTO as one could edit the subsequent actions without having to keep moving the label from statement to statement]

	BREAK/CONTINUE tended to come later, when they were deemed a safe (ie;
structured) alternative to the GOTO statement.

Hairy Pixels via fpc-pascal said on Tue, 20 Jun 2023 14:05:04 +0700

I'd have to take a time machine back to the early 1980's to find out their opinions on early function exit, but judging from their underlying philosophies I'd guess they'd have a problem with early exits from functions.

Their tude isn't completely stupid if you look at it from the viewpoint of the early 1980's. Flowchart-designed spaghetti code and the proud and stubborn spaghetti chefs creating it were still very prevalent, resulting in programs increasingly difficult to bring to completion, modify or maintain. By FAR my educators' priority was to teach us modular programming: 1 entry point, 1 exit point, no global variables, no gotos, no goto-lights (break, continue, exit). With what they taught us young turks, we went out and replaced the spaghetti chefs everywhere except the mainframe.

As we young turks got some experience, we realized the orthodoxy we learned in school wasn't necessary. We realized that in 30 line loop body, putting three continue statements at the top was a heck of a lot more readable than three levels of indentation. We realized that in a 30 line loop body, with multiple things being able to stop the loop and not just a counter, sometimes a break statement was more readable than a monstrosity logic part of the while statement, and all the if statements to prevent certain parts from being executed. So yeah, we used some stupid ideas in the real world, but those stupid ideas completely eliminated spaghetti programming, so our super-productivity displaced the spaghetti guys, giving us some time to moderate the orthodoxy with common sense.

One of the things I truly appreciated about Pascal was that it not only promoted modular programming, but it also made it difficult to spaghetti. It was a long time ago, but if I remember correctly the Whitesmith Pascal and Turbo Pascal 2 and 3 had either break or continue. If I remember correctly, I first learned about those when learning C.

Thanks,

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm

Steve Litt wrote

It was a long time ago, but if I remember correctly the Whitesmith Pascal and Turbo Pascal 2 and 3 had either break or continue. If I remember correctly, I first learned about those when learning C.

i'm confused about your statement... first you say break/continue existed in one of two pascal dialects but then you say you first learned about the two keywords in C... ummmm, wut?

in any case, Break/Continue did not appear in Turbo/Borland Pascal until v7 in 1992... i posted about that in this thread on the morning of the 18th about 7:20AM Eastern US time...

wkitty42--- via fpc-pascal said on Wed, 21 Jun 2023 08:07:59 -0400

I meant to say "neither" instead of "either". Sorry for the confusion.

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm

that does make a difference :) thanks...

I mostly agree with that programmers. That's called structured programming.  "Break" and "continue" are in fact, a subset of GOTO

When you see a structure, a block, you know at the beginning (or end of the block) the exit conditions. So you can skip the block and you know the conditions after the block. It is very useful when you are skimming the code or debugging. You don't have the investigate the inner loop to see if there are hidden GOTOs.

But, as any other golden rule, you must know when it makes sense to ignore it.
I use the break, but only at the beginning of the loop. (or exit in function/procedure)
And sometimes with deep nested loops, but, when I commit such crime, I highlight it with neon lights in the comments.

I really hate having the read the full code to guess whats happening. Structured programming  is your friend.

Santi via fpc-pascal said on Sat, 1 Jul 2023 10:22:48 +0200

I agree, although they're less damaging than goto, which I haven't used since 1982 using 6800 hex machine language, where I learned how much less damaging jump to subroutine and return from subroutine are than goto.

I agree, although there are some practical concerns, which you go on to mention...

I tend to put continue statements at or near the top of the block, to summarily rule out some obvious irrelevant iterations without all sorts of if/then/else nesting. As a practical matter it's more readable and more maintainable.

Also, when I'm in a rush, I'll do while(True) and then just put one or more breaks in the block, with the full intention of going back and doing it the right way, but then forget to. I apologize to the maintenance programmer who follows me, because this is bad practice.

Sometimes I use breaks when the loop test condition would be so hairy as to be difficult to understand. This happens a lot when things get very stateful. But your post got me to thinking that maybe this is a symptom that I made a poor design.

I really hate having the read the full code to guess whats happening. Structured programming  is your friend.

Xactly!

SteveT

Steve Litt
Autumn 2022 featured book: Thriving in Tough Times http://www.troubleshooters.com/bookstore/thrive.htm

Swift has decided to build this pattern into the language. I kind of like it but it's also kind of messy looking and a continue at the top of the block often is easier to read for me. In pascal it would look like this:

for item in list where item.value > 10 do
  begin
  end;

Which would be the same as:

for item in list do
  begin
    if item.value <= 10 then
      continue;
  end;

or with traditional for loops but this really looks bad.

for i := 0 to list.Count - 1 where list[i] > 10 do
  begin
  end;

Regards,
Ryan Joseph