🚀 go-pugleaf

In <4321kd$cne@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
:Here is the _until_ statement, the situation-driven control construct. It
:declares a situation indicator that has scope in the following statement, which
:is typically an iteration or compound statement.
:
:    until <identifier>
:        <statement>
:
:When the identifier is subsequently encountered in the statement, control
:leaves the statement. IOW, control continues through the statement until this
:situation occurs. That simple. Here is part of a tree-search-and-insertion
:scheme from Knuth that uses a situation indicator with a for statement:
:
:    until leaf_replaced for (;;) {
:        if (a[i] < x) {
:            if (l[i] != 0) {
:                i = l[i];
:            }
:            else {
:                l[i] = j;
:                leaf_replaced;
:            }
:        }
:        else {
:            if (r[i] != 0 {
:                i = r[i];
:            }
:            else {
:                r[i] = j;
:                leaf_replaced;
:            }
:        }
:    }
:    a[j] = x; l[j] = 0; r[j] = 0; j = j + 1;

How does this differ from a labelled control structure?  As I remember,
situation labels (NOT indicators) were designed to handle the problem
of multiple exits from a loop.  So the notation is closer to the original
intent.  However, I would favor syntax something like...

   loopName::for (;;) {
         statements...
         loopName::exit label2;
         loopName::redo;
         loopName::exit;
         loopName::quit;
         statements...
      exit label1:
         statements...
         exit label3;
         statements;
      exit label2:
         statements;
      exit label3:
         statements;
      default:
         statements;
      }

Where "loopName" is optional, but allows nested loops to be handled
correctly.  Here, "redo" repeats the loop (as "continue" current does),
"quit" exits the loop entirely (as break currently does), and "exit" with
a label exits the loop after executing the statement block with the
defined label, and "exit" without a label exits the loop after executing
the statement block with the "default" label.

The exact syntax could be quibbled over for weeks because of the
need to make it "look" something like C.  The advantage of this syntax
is that the similarity to the switch/case control structure is very
clear.  The for loop itself ends at the first "exit label" or the closing
brace, whichever occurs first.

The "exit label3;" statement is more iffy (pardon the pun <G>) but
the point is that an exit block could contain another exit statement
(or quit statement, but not redo statement) as long as a "forward"
reference is used.  So, "exit label1;" could not be used in "exit label2:"
or in "exit label3:".

:It might take a week or two to
:integrate this language feature into an existing compiler. Not a big deal.

The same is true of my version -- and I have done so in a compiler I
was playing with.

:I'd vote no on multiple situation indicators.

Without them you have nothing more than a labelled control
structure.  Which is nice, but your syntax is drastic overkill for
that.  And it should apply to the "continue" statement as well
as the "break" statement.  It is often necessary to start the
next loop immediately.  I use "continue" just about as often as
I use "break".

:Knuth also allows situation indicators to pass arguments to their counterparts
:in the then clause. Nice, but we gotta draw the line somewhere. :-)

I seriously considered that, but then the situation label becomes
essentially a computed jump to a nested subroutine.  I have to agree
that seems a bit much for the purpose.

:There is some value in not having a zillion ways to do something.

No, I want a zillion and two! <g>  Seriously, I think that Wirth
has done more to set back the development of programming
languages more than any other individual before (and hopefully
since).

This "one way and one way ONLY to do something" is directly
opposed to the concept of semantic richness.  I would rather
have several variants of a control structure so that I can choose
the one that is "just right" rather than have to always work
around the ONLY thing provided.

I also prefer to speak English rather than Esperanto.  Those who
belive as Wirth do in "one and only one way" and who do not
speak Esperanto are philosophically inconsistent.

:What do you think?

Now you know! <g>  Start flaming!

Michael Lee Finney