🚀 go-pugleaf

In article 435n1u$bho@mujibur.inmind.com, mfinney@inmind.com writes:
>In <4321kd$cne@news0.rain.rg.net>, Paul Long <plong@perf.com> writes:
[snip:situation indicators syntax and example]
>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...
[snip:Michael's syntax and semantics]
>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.

That's a specious argument. I can imagine advantages and disadvantages of it
being similar to the switch statement. And frankly, both of our syntaxes are
really ugly. :-P

[snip]

>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:".

Sounds familiar. I think Knuth also considered this for situation indicators.

>: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.

Cool.

>: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".

I just never encounter situations where a continue statement would be useful--I
don't think that way. I recently found this in another programmer's code:

    while (x) {
       if (y) {
          continue;
       }
       a;
    }

that could have been more clearly written, IMO, as:

    while (x) {
       if (!y) {
           a;
       }
    }

And if one uses a continue statement deep inside nested if statements, first of
all, chances are that that function is entirely too complex (as in functional
complexity, such as cyclomatic). Also, there's a good chance that one has
painted oneself into a corner and the most obvious and quickest solution is to
jump over all that nasty logic that follows and "goto" the top of the loop.
BTW, I think that this is also why goto is abused. And I mean really badly
abuses, too, not like the thoughtful applications that have been recently
posted here.

For the same reason that I wouldn't include, for example, a computed-goto
statement in a language, neither would I include a continue statement--I don't
see a need. Languages are usually a very personal, subjective expression of
"good programming" on the part of the designer, and I don't mean to imply that
your catering to the continue statement makes you an inferior programmer, etc.
It's just not how I see the world. I'm sure... no, I'm certain :-) ... that you
would feel the same way about things that I would put in a language.

[snip:neither of us want situations to pass arguments]

>: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.

You'd like PL/I. A problem with a "rich" language is that dialects are formed.
In practice, a language like this turns into a set of related dialects. We use
a small subset of the language and continue to use just that subset because we
are familiar with it. A programmer who speaks one dialect may not understand
another dialect. The guy that we hire who knows language X may not understand
our use of language X because he knows X' and we use X'', and their
intersection may be minimal.

>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.

That's silly. Do you think he should also make, for example, only left-hand
turns so that he turns in "one and only one way." Come on.

-- 
Paul Long                               45:29:14N 122:48:09W
plong@perf.com                          http://www.teleport.com/~pciwww/
    "Where time or intelligence are lacking, a goto may do the job."
        - M.E. Hopkins, "A Case for the GOTO," 1972.