7

When published in 1970, the Pascal language did not have a way to implement the functionality equivalent to the (future) C language operators "break" and "continue". Their convenience having been recognized, extended dialects of Pascal have started to feature similar operators.

From the same documentation for an implementation of Pascal for a Soviet computer as here, dated 1979:

In accordance with the ideas of structural programming and the requirements of programming practice, the following control structures are introduced in the language:

Structural labels

An operator can be labeled with a structural label.

<operator> ::= { <label>: }* { ( <structural label> ) }* <unlabeled operator>

<structural label> ::= <identifier>

The scope of a structural label is the unlabeled operator.

exit operator

Within the scope of a structural label, e. g. "(M)", there may be operators exit M, equivalent to exiting the corresponding unlabeled operator.

Syntax

<exit operator> ::= exit <structural label>

goto operator

Syntax

<goto operator> ::= goto ( <label> | <structural label> )

A goto operator using a structural label may appear within the scope of that structural label. Its function is equivalent to the regular goto operator.

Structural labels realize the right of each operator to iterate and to complete.

(Most readers of the documentation would later misquote the last statement as "the inalienable right of each operator to iterate and to complete".)

TL;DR: Structural labels implement mechanisms akin to generalized "break" and "continue" operators on the C language. For example:

(outerloop) for i := 1 to 100 do
(innerloop) for j := 1 to 100 do
     (iter) begin
            ...
            exit iter; { same as continue in C }
            ...
            exit innerloop; { same as break in C }
            ...
            exit outerloop; { no convenient C analog }
     end

Unlike regular numerical labels in Pascal, structural labels did not need to be pre-declared.

Turbo Pascal appeared in the 1980s and seems to have regular C-like break and continue.


The question is: Has any pre-1979 dialect of Pascal featured "structural labels", or any kind of break/continue functionality?

Leo B.
  • 19,082
  • 5
  • 49
  • 141
  • I don't understand the "the inalienable right" part - is that the Pascal equivalent of Not Enough jQuery? – wizzwizz4 Jul 12 '17 at 20:43
  • @wizzwizz4 I had to look that meme up; no, I think "inalienable" was used to argue with those who had deemed the feature superfluous and claimed that numerical labels should be enough for everybody. – Leo B. Jul 12 '17 at 20:48
  • 8
    Given that Nikolaus Wirth (together with others like Dijkstra) was one of the main proponents of "structured programming", adding goto and exit to Pascal is of course a complete perversion of his ideas. These "features" were missing on purpose, not because of some "oversight". So the answer is probably "as soon as enough time had passed that there were people who didn't understand what Pascal was about, and had to muck with it, and were far enough removed from the creator so he couldn't berate them". – dirkt Jul 13 '17 at 06:58
  • @dirkt In case you haven't noticed, those goto and exit cannot jump to arbitrary places but only to the beginning and to the end of structured operators, very much like break and continue. Niklaus Wirth had 35 years and counting to express objection to break and continue in Turbo Pascal. Has he ever? – Leo B. Jul 13 '17 at 07:04
  • 3
    I perfectly know, and I don't object to break/continue (or other forms of "tamed" gotos). I don't think Wirth would publicly express objection, but he didn't include break/continue in Oberon (1986, last revision 2016 by himself) either. Does that count? :-) – dirkt Jul 13 '17 at 08:58
  • 1
    The point is that the question as it stands makes no sense: It's not like this was forgotten, and then suddenly people realized this and said "oh, let's introduce it", and after that every Pascal dialect did it that way. Instead, it's a matter of taste, and whether the people writing the Pascal compilers did have different ideas of how the language should look like. So there's no "first", no "introduction", just people's taste. Wirth was in all likelyhood perfectly aware of this construct when he designed Pascal. – dirkt Jul 13 '17 at 09:00
  • 1
    Also see here his reaction to the modest changes UCSD Pascal introduced: "When UCSD Pascal began to spread, their tinkering with Pascal raised a fair amount of ire from some quarters, not least from Wirth himself, a pedantic sort who regarded the language in its original form as perfect, with everything it needed and nothing it didn’t." – dirkt Jul 13 '17 at 09:15
  • 1
    @dirkt The language was designed for education, so I don't blame Wirth for not including break and continue or equivalents in the first version (or even for continuing this stubbornness). But as soon as the language is to be used for engineering, using "tamed gotos" is not a matter of taste, it is a matter of good programming practice. Therefore the point of the question is to find out which dialect of Pascal first catered to actual software developers. – Leo B. Jul 13 '17 at 15:16
  • Wirth was a minimalist, and that's how he wanted the language - after all, it was his language. The spin "when did Pascal first cater to actual software developers" makes as little sense as the original question (sorry) - the whole UCSD Pascal OS was written in a Pascal "not for actual software developers" (so apparently they shouldn't have been able to write it, then). As were plenty of other programs. It is a matter of taste, not of good programming practice (though I personally prefer to have it, just like you do). – dirkt Jul 13 '17 at 15:22
  • @dirkt Me: "the whole UCSD Pascal OS was written in a Pascal "not for actual software developers" (so apparently they shouldn't have been able to write it, then)". That does not follow. Should be "so apparently their productivity level and/or code quality was not that it could have been". – Leo B. Jul 13 '17 at 16:16
  • Hmm, one problem here might be the 'any pre-1979 dialect of Pascal' requirement, as PASCAL wasn't realy intended to be used as a language in the first place. It was just an example for a language used by Wirth in his complier class. As a result, next to every other student at ETH did create his own dialect :)) – Raffzahn Jan 04 '18 at 22:45
  • 1
    Pascal is OK as a teaching tool. Using it as a production language is really painful - no separate compilation, no hardware interface (unless it was memory mapped), no threads. Any usable version was a dialect. It was also quite slow because of the p-code interpreter. I had to use UCSD Pascal for a production system once. It couldn't be batched and the manuals for using p-code were difficult to get hold of. There wasn't any facility for multi-tasking either. – cup Jan 05 '18 at 12:14
  • 1
    @cup Nothing in the definition of Pascal makes it a requirement to use p-code. Pascal compilers could and frequently did compile to native code. The lack of threading also would not have been considered a disadvantage in the 1970's and 80's because no common language had threads at that time. C didn't even have IO. – JeremyP Jan 05 '18 at 17:24
  • @cup: Turbo Pascal 3.0 didn't support separate compilation except by using manual overlays, but could still manage an edit-compile-run-edit cycle faster than systems that used separate compilation. A number of notable programs, including the original Tetris, were produced using Turbo Pascal. – supercat Jan 08 '18 at 16:46
  • @supercat Separate compilation isn't anything to do with speed: it is a dependency build. This is different from independent compilation. – cup Jan 08 '18 at 19:09
  • @cup: Turbo Pascal allowed a program to be built using multiple source files, though if they were on floppies that would of course severely degrade compile speed. Having different source files use different prefixes for "private functions" and variables is semantically essentially the same as having separate compilation units, provided no two files pick the same prefix. – supercat Jan 08 '18 at 19:17

3 Answers3

9

It is difficult to say for sure, because there have been a lot of implementations of the Pascal Language (some of them not very widely distributed), each with their own specific additions to the language.

Anyway, my researchs show that it is very unlikely that a feature like the one you describe have been made available before 1979:

  • The Turbo Pascal compiler (which has certainly been one of the most widely ditributed Pascal implementations, and stands, at least for me, as a reference) has, indeed, introduced break/continue statements, but not before the 7.0 version, released in 1992. See the reference manuals available here. In a paragraph named "Flow control procedures", you'll see the break/continue statements are mentioned for the 7.0 version, but not for the 6.0 version.
  • The Pascal MT+, released in 1980, show no such thing in its reference manual (available here).
  • The UCSD Pascal, released in 1978, is simply based on the Wirth definition of Pascal with a few additions, but nothing that looks like a break/continue statement (manual here).

I made some additional researchs on other implementations, but almost all of them are said to be close to the ISO 7185 standard, and I couldn't find the manuals online.

Anyway, the fact that Borland introduced this feature so late (and that nobody answered this question yet) should be convincing enough. I may have missed some very obscure implementations, though (like the one you mention).

dim
  • 1,608
  • 12
  • 17
1

From the beginning Pascal has always had a goto statement. So while it didn't have explicit break and continue, they were trivially easy to emulate:

while someCondition do
  begin
    2: 
    (* do some stuff *)
    goto 1; (* Equivalent to break *)
    (* do some more stuff *)
    goto 2;
    (* do even more stuff *)
  end;
1:

break and continue are more convenient of course but they are essentially just goto statements and personally I really don't like them. I've never used continue and I only use break in C switch statements.

JeremyP
  • 11,631
  • 1
  • 37
  • 53
  • This has received a NAA flag. I'm not certain why; numerical labels are mentioned in the question but this seems to have the desired effect... Are there any caveats that you know of? – wizzwizz4 Jan 05 '18 at 17:09
  • 1
    @wizzwizz4 Well no. I would certainly argue that the two goto examples in my answer count as analogues of break and continue - they do the same thing. They are obviously not precisely identical with break and continue. – JeremyP Jan 05 '18 at 17:14
  • 1
    @wizzwizz4 This answer doesn't even begin to actually answer the question, and offers a personal opinion instead. – Leo B. Jan 05 '18 at 17:50
  • @LeoB. Question: "When were the analogs of the C operators [...] introduced in Pascal?" Answer: "From the beginning Pascal has always had a goto statement [which can be used to emulate break and continue]." I don't see the problem; please elaborate. – wizzwizz4 Jan 05 '18 at 17:52
  • @wizzwizz4 "Which can be used to emulate" does not make an analog. From a software engineering standpoint, it is a very poor replacement. In the example above, there is no way to make sure that the label 1: will always be directly after the end; of the loop, making the code fragile. – Leo B. Jan 05 '18 at 18:15
  • 2
    The question explicitly asks for break/continue or structural labels, which OP defined as "not needing to be predeclared". This is not the case of goto labels, so I don't think this answer fits. – dim Jan 05 '18 at 20:46
  • @dim If you think it is a bad answer, downvote, don't flag for moderation. In any case, whether you like it or not, the goto examples I gave are the analogue of break and continue, predeclared labels or not. The objection is just splitting hairs. – JeremyP Jan 15 '18 at 09:57
  • @Jeremy I didn't flag. The flag has likely been raised by Leo. I agree flags aren't appropriate here, even if the answer is arguably not fitting the question. I didn't want to downvote either. I just wanted to express why I personally think this answer isn't quite right, since there seemed to be a debate there. As an aside, this also gave the occasion for me to say why I didn't mention goto in my own answer. – dim Jan 15 '18 at 10:59
  • 1
    This is actually answering the question why break and continue came so late in the game - They were not explicitly needed because goto provided the functionality, and apparently the creators of the language didn't want to make it too easy to allow non-structured programming. – tofro Jul 04 '18 at 12:32
-3

Because break and continue are a form of goto. To see why lets review basic Pascal structures a bit (at least those that would be applicable to break and continue):

while x do y; repeat y until x; for i := s to e do;

Taking one of them:

while x do begin

  s1;
  s2;
  s3;

end;

Using C breaks you could break anywhere in that sequence:

while x do begin

  break;
  s1;
  break;
  s2;
  break;
  s3;
  break;

end;

You can substitute "continue" for "break" anywhere in the above.

All Pascal structured statements have the characteristics that:

  1. They have a single point of control entry.
  2. They have a single point of control exit.

Thus with break and continue you change "single point of exit" to (basically) anywhere. Its only limitation is that it must be contained within the loop.

Structured programming is based on the idea that with a few simple single entry/single exit constructs you can write any program. It sometimes is not easy, which is why break and continue exist in C and other languages.

So the above example is trivial, but imagine going through a loop that spans a page or more. It can be a challenge to find what is or is not executed within the loop.

Similarly, compilers can also have difficulty unwinding the different paths through the code, and what the compiler can not easily determine means that it cannot also readily optimize for it.

Scott Franco
  • 139
  • 2
  • Clearly, you don't understand the notion of single point of control entry or exit. The "break" and "continue" operators can always be modeled with conditional operators and flags, therefore they are perfectly fine for structured programming. The Pascal compiler referred in the question which supports an even more general constructs than "break" and "continue", only takes a few dozen lines to implement them. – Leo B. Jul 04 '18 at 06:06
  • if is also a form of goto; specifically, a conditional goto. In any language that has if and else, any statement on the form "if x = y then abc else def endif" can be rewritten on the form "if not (x = y) then goto z; endif; abc; goto end; label z; def; label end;". In fact, I'd be very surprised if that's not awfully close to the machine code generated for most if constructs by almost any compiler for almost any language and target architecture. – user Jul 04 '18 at 14:46
  • "The "break" and "continue" operators can always be modeled with conditional operators and flags," then use that. The problem is that break and continue are open ended statements. "if is a form of goto" No, it is self contained (same answer as the last). To get to the point, sure, you could write a complete program using nothing but gotos, and then a compiler could create a tree graph from the entire thing and just figure it out. That's not the issue. These are open ended statements. You can't tell at a glance what the control structure being presented is. (cont) – Scott Franco Aug 20 '18 at 20:20
  • The idea of structured statements is, especially if the program is properly indented, you know just where the entry is, and where the exit is, and where the body of the statement is. Everyone agrees that goto code does not have that property, but break and continue statements also break the internal structure of structured programming basic blocks. The typical argument for those statements is "its too hard" [to do real structured programming]. This is not new, its been going on since Dijkstra. I don't program with them, even when doing C/C++, and it is second nature to me. (cont) – Scott Franco Aug 20 '18 at 20:28
  • Further, I rarely need flags to help that process along. In fact, Pascal's strict rules about expression evaluation, needing to eval an expression that has issues like: if (i < 10) or (a[i] = 0) where the array a[] only has 10 elements, causes more issues, but even that has good workarounds. Is it worth the trouble? I think so. Structured programming reads better and is easier to debug. Putting statements to break it in the language is institutionalizing laziness, IMHO. – Scott Franco Aug 20 '18 at 20:38