🚀 go-pugleaf

Like Andrew, I personally prefer named loops to multi-level "break"s.  Once
you're in maintenance mode, you may wind up inserting and deleting loops --
which may inadvertently change the number of levels from which you must
break.  Grammatically however, I'd suggest something more like perl's "last
Label" approach.

Basic idea: A label binds to the following statement.  When you "break
Label", you goto the statement following the labeled statement (i.e., the
second statement after the label).  Thus, Andrew's example would be
written:

outer:
for (x = 0; x < MAXX; x++)
{
   inner:
   for (y = 0; y < MAXY; y++)
   {
      if (map[y][x] == '*')
         break outer;
   }
}

Thus, only the grammar of the "break" statement itself would change.


A similar useful construct in perl is "redo", which restarts a loop at the
top without checking the looping condition and without executing the third
"for" expression.  E.g.,

outer:
for (x = 0; x < MAXX; x++)
{
   topOfOuter:
   doStuff();

   inner:
   for (y = 0; y < MAXY; y++)
   {
      if (map[y][x] == '*')
         redo outer;
   }

   bottomOfOuter:
      ;
}

In the above example, "redo outer" is equivalent to "goto topOfOuter".
Also, why not add a labeled "continue" as well (like perl's labeled
"next").  In the above example, "continue outer" would be equivalent to
"goto bottomOfOuter".


Implementing labeled "break" and continue" should be no more difficult to
implement than the equivalent "goto"s, and only slightly more difficult
than the current "break" and "continue" -- and that only because you
potentially have to access the end of any labeled loop, not just the
innermost loop.  Currently, this information must be maintained anyway to
handle unlabeled "break"s and "continue"s that potentially follow the
innermost loop.  Redo should be slightly easier to implement than the
current break and continue, since it always translates into a goto with the
destination already resolved before encountering the redo.

Someone brought up lost opportunities for optimization due to the use of
labels.  That much is true, however, the alternative to labeled "break",
"continue" and "redo" is "goto Label" -- and a label -- with the same loss
of potential optimizations.

In all three cases, the change to the grammar would be minimal.  Only
"break", "continue", and the addition of "redo" would change.  (I suggest
paren's not be used or allowed.)  Granted, this is pure syntactic sugar --
just like the existing "break" and "continue".  Also like the existing
"break" and "continue", the result allows somewhat more abstract and
maintainable code to be written.


	Chuck Phillips	cphilli@lookout.ecte.uswc.uswest.com
#include <std/disclaimer.h>