Loop While Control Flow

[brianoh]

The following was proposed by Dahl in 1972 (Wikipedia) and was/is used in at least one programming language that I know of. I think it is very powerful and makes for cleaner code. I have encountered many situations where this control structure would have been beneficial and enhanced structured coding.

From Wikipedia:
"Donald Knuth's 1974 article "Structured Programming with go to Statements",[29] identifies two situations which were not covered by the control structures listed above, and gave examples of control structures which could handle these situations. Despite their utility, these constructs have not yet found their way into mainstream programming languages."

Eg from Wikipedia:

   loop
       read(char);
    while not atEndOfFile
        write(char);
    repeat;

Or alternatively pseudocode:

loop {
   input data;
} while (data.len > 0) {
   fnProcessData(data);
}

[micttyl]

Hello, @brianoh. It looks like Knuth was working on some application at that time.
I think It could be like this in Carbon(isn't it cool?)

while(true) {
    dataq.ReadOrIdle(stream);
    for (var d: Foo in dataq) {
        dataq.Process(d);
    }
}

[OlaFosheimGrostad]

I think what was suggested was this:

while (true) {
    let ch:auto = get();
    if (ch != EOF) break;
    put(ch);
}

[brianoh]

To some (including me), the break statement is as bad as to goto statement. That is my opinion because break does not conform to the strict structured programming paradigm. I do understand that people use it because the alternative is more verbose. It's unfortunate that I mentioned Knuth, because apparently, he thought that the GoTo was acceptable, but I'm sure those in agreement now would be miniscule in number. As someone who has had to unscramble GoTo spaghetti, I find the GoTo abhorrent, and consequently I dislike the break statement.

The following are two examples of structured programming. The first is actual, and the second is theoretical in c/cpp currently. It is valid in at least one other programming language that I've discovered (with a different syntax).

I think that the theoretical "loop" code below (or similar) should be supported in Carbon because it would enable more strict observance of structured programming techniques and consequently would result in better programs for that reason.

First example: (Valid code)

#include <stdio.h>
#define I_MAX 20
int main() {
  char sEntry[I_MAX+1];
  do {
    fgets(sEntry, I_MAX, stdin);
    if (sEntry[0] != char(10)) {
      puts(sEntry);
    }
  } while (sEntry[0] != char(10));
}

**Second example: (theoretical) **

#include <stdio.h>
#define I_MAX 20
int main() {
  char sEntry[I_MAX+1];
  loop {
    fgets(sEntry, I_MAX, stdin);
  } while (sEntry[0] != char(10)) {
    puts(sEntry);
  }
}

[jonmeow]

First, I would suggest that while break and continue could be argued to be goto-like, their consequence on control flow is significantly different and closer to return. An early return is something that I'm familiar with as a good coding practice, and I consider break and continue in the same bucket.

From my perspective, the issue with goto is that it can create arbitrary control flows which negatively impact understandability of code; instead of a linear traversal, a function might hop around to various points within the containing scope. This can make it hard to reason about construction and destruction of objects, or even what the actual control flow is.

By comparison, break and continue end a control flow early in a narrowly specified manner: returning to the condition of the closest loop scope. It can sometimes be difficult to figure out what the closest loop scope is, but hopefully something like labeled break/continue might offer a remedy for that.

return is similarly narrow: it exits the current function scope.

Second, I would note the issue of removing break when it's used with a little more conditional nesting:

do {
  int x = Consume();
  if (x == -1) {
    int y = ExpensiveCall();
    if (y == -1) {
      break;
    }
    x = Mutate(x, y);
  }
} while (x > 0);

There are surely ways to refactor this to get rid of the break. However, I think that as loop contents become progressively more complex (more content, maybe one or two more layers of scope depth, etc), it's going to be hard to write efficient, readable code that does not use break.

I do think there's interest in providing different loop semantics, particularly to provide an alternative for C++'s for (;;) loop style. I'm not sure what form that will take, or if it'll succeed (i.e., for (;;) may work its way in simply as a familiar construct). I think it'd be harder to remove break and continue because they simplify a common semantic for loops.

[brianoh]

Thanks for the replies. I don't suggest removing "break" and existing programs use it. I only suggest an alternative for those who prefer a more strict adherence to structured programming. IE. Only one exit from a loop. I find the two-stage loop a very good alternative. Also, obviously many existing programs use "break" so it is needed for them. C++ also has a "goto" which hopefully no one uses, but there may be a case that I haven't encountered where it is needed.

…

On Thu, Sep 29, 2022 at 2:25 AM Jon Ross-Perkins ***@***.***> wrote: First, I would suggest that while break and continue could be argued to be goto-like, their consequence on control flow is significantly different and closer to return. An early return is something that I'm familiar with as a good coding practice, and I consider break and continue in the same bucket. From my perspective, the issue with goto is that it can create arbitrary control flows which negatively impact understandability of code; instead of a linear traversal, a function might hop around to various points within the containing scope. This can make it hard to reason about construction and destruction of objects, or even what the actual control flow is. By comparison, break and continue end a control flow early in a narrowly specified manner: returning to the condition of the closest loop scope. It can sometimes be difficult to figure out *what* the closest loop scope is, but hopefully something like labeled break/continue might offer a remedy for that. return is similarly narrow: it exits the current function scope. Second, I would note the issue of removing break when it's used with a little more conditional nesting: do { int x = Consume(); if (x == -1) { int y = ExpensiveCall(); if (y == -1) { break; } x = Mutate(x, y); } } while (x > 0); There are surely ways to refactor this to get rid of the break. However, I think that as loop contents become progressively more complex (more content, maybe one or two more layers of scope depth, etc), it's going to be hard to write efficient, readable code that does not use break. I do think there's interest in providing different loop semantics, particularly to provide an alternative for C++'s for (;;) loop style. I'm not sure what form that will take, or if it'll succeed (i.e., for (;;) may work its way in simply as a familiar construct). I think it'd be harder to remove break and continue because they simplify a common semantic for loops. — Reply to this email directly, view it on GitHub <#2214 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWYAMWVJ2PBZL2GPW4UR3WASEQBANCNFSM6AAAAAAQURSH6U> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>

[jonmeow]

I only suggest an alternative for those who prefer a more strict adherence to structured programming. IE. Only one exit from a loop. I find the two-stage loop a very good alternative.

We should certainly look for syntaxes that work well in multiple situations. I think there's interest in a loop keyword that replaces while (true), simply because it's so common. To try to get a grasp on scale, here's a search of while (true) loops: example; that finds over 1.1m uses.

The thing about a two-stage loop structure is that it's going to be some subset of that. I'm not sure how large or small: one example search finds 100k results, although removing some false positives suggests more like 80k.

It may be though that the kinds of syntax we would want for a more generic loop structure would simplify well for the two-stage loop structure use-case. That's the ideal scenario: that we provide a generic syntax which can be reused to address multiple use-cases.

C++ also has a
"goto" which hopefully no one uses, but there may be a case that I haven't
encountered where it is needed.

I think it's important to understand goto has its uses -- it creates complex control flows, but sometimes complex control flows are necessary for performance, which I think comes up particularly often when people are trying to write high-performance parsers. Here are a few quick examples:

https://github.com/abseil/abseil-cpp/blob/master/absl/strings/escaping.cc#L463
https://github.com/abseil/abseil-cpp/blob/master/absl/strings/numbers.cc#L147
https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp#L8274
https://github.com/boostorg/format/blob/develop/include/boost/format/parsing.hpp#L135

As we discuss language design, it's important to bear in mind that most language features have their pros and cons. goto might be best used with caution, but at the same time, sometimes unusual control flows are helpful in writing high-performance code.

[brianoh]

@jon Thanks for that info. I accept that all languages have their pros and cons, however, I'm sure that Carbon will reduce the cons found in predecessors and introduce new improvements. I hope that it is as ground-breaking as "C" was. I think the following would be worthy enhancements: 1. As mentioned, a two-stage loop structure. Had I never encountered it, perhaps I would not have a huge desire for it. 2. As mentioned, a very-concise case structure that does not require a "break". 3. Elimination of overly complex and in some cases two words for a data-type (eg: "long long"). The proposed data-type names in Carbon look great to me (concise and informative). Brian

…

On Sat, Oct 1, 2022 at 1:11 AM Jon Ross-Perkins ***@***.***> wrote: I only suggest an alternative for those who prefer a more strict adherence to structured programming. IE. Only one exit from a loop. I find the two-stage loop a very good alternative. We should certainly look for syntaxes that work well in multiple situations. I think there's interest in a loop keyword that replaces while (true), simply because it's so common. To try to get a grasp on scale, here's a search of while (true) loops: example <https://sourcegraph.com/search?q=context:global+lang:c%2B%2B+%28%3Fm%29while%5Cs*%5C%28true%5C%29+count:10000000&patternType=regexp>; that finds over 1.1m uses. The thing about a two-stage loop structure is that it's going to be some subset of that. I'm not sure how large or small: one example search]( https://sourcegraph.com/search?q=context:global+lang:c%2B%2B+%28%3Fm%29while%5Cs*%5C%28true%5C%29%5Cs*%5C%7B%5B%5E%7B%7D%5D%2B%3F%3B%5B%5E%7B%7D%5D%2B%3Fif%5Cs*%5C%28%5B%5E%7B%5D*%5C%29%5Cs*%28break%3B%7C%5C%7B%5Cs*break%3B%5Cs*%5C%7D%29%5B%5E%7B%7D%5D%2B%3F%3B%5B%5E%7B%7D%5D%2B%3F%5C%7D+count:10000000&patternType=regexp) finds 100k results, although removing some false positives <https://sourcegraph.com/search?q=context:global+lang:c%2B%2B+%28%3Fm%29while%5Cs*%5C%28true%5C%29%5Cs*%5C%7B%5B%5E%7B%7D%5D%2B%3Fif%5Cs*%5C%28%5B%5E%7B%5D*%5C%29%5Cs*%28break%3B%7C%5C%7B%5Cs*break%3B%5Cs*%5C%7D%29%5B%5E%7B%7D%5D%2B%3Fif%5Cs*%5C%28%5B%5E%7B%5D*%5C%29%5Cs*%28break%3B%7C%5C%7B%5Cs*break%3B%5Cs*%5C%7D%29%5B%5E%7B%7D%5D%2B%3F%5C%7D+count:10000000&patternType=regexp> suggests more like 80k. It may be though that the kinds of syntax we would want for a more generic loop structure would simplify well for the two-stage loop structure use-case. That's the ideal scenario: that we provide a generic syntax which can be reused to address multiple use-cases. C++ also has a "goto" which hopefully no one uses, but there may be a case that I haven't encountered where it is needed. I think it's important to understand goto has its uses -- it creates complex control flows, but sometimes complex control flows are necessary for *performance*, which I think comes up particularly often when people are trying to write high-performance parsers. Here are a few quick examples: https://github.com/abseil/abseil-cpp/blob/master/absl/strings/escaping.cc#L463 https://github.com/abseil/abseil-cpp/blob/master/absl/strings/numbers.cc#L147 https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp#L8274 https://github.com/boostorg/format/blob/develop/include/boost/format/parsing.hpp#L135 As we discuss language design, it's important to bear in mind that most language features have their pros and cons. goto might be best used with caution, but at the same time, sometimes unusual control flows are helpful in writing high-performance code. — Reply to this email directly, view it on GitHub <#2214 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAWYALKCBMBYYM36LVPE73WA4NN5ANCNFSM6AAAAAAQURSH6U> . You are receiving this because you were mentioned.Message ID: ***@***.*** .com>