🚀 go-pugleaf

erik@kroete2.freinet.de (Erik Corry) wrote:

>Fredrik Bredberg (konfrbr@euax7i3c01.eua.ericsson.se) wrote:
>: Andrew Dunbar (andrewd@agnus.livewire.com.au) wrote:
>: :
>: : Has anyone thought of the possibility of 'named' loops?
>: :
>: : for outer (x = 0; x < MAXX; x++)
>: : {
>: :    for inner (y = 0; y < MAXY; y++)
>: :    {
>: :       if (map[y][x] == '*')
>: :          break (outer);
>: :    }
>: : }

>: I think that Andrew's `named' loops is the best alternative to this
>: problem that I'v seen so far! The main reason for this is that the
>: `label' is so closely coupled to the loop constructor.

>What I think is wrong with 'named loops':

>1) It's a completely new syntax for C. This makes learning it difficult.

It's the right kind of syntax extension.  Any current legal C programs
compile with the same semantics as before.  Programs written with the
new syntax will cause syntax exceptions on old compilers, thus
immediately pointing out the problem.

>2) It's a completely new syntax for C. This makes parsing it difficult.

Yeah, right.  I see no possible ambiguity.  Only an open paren or
label may follow "for".

And similarly, only a label may follow "break" or "continue".

>   Specifically it looks like a function call inner() yet it is actually

How could it be a function call?  Even if you ignore the reserved word
"for" there's no way the contents of the parentheses could be mistaken
for function arguments, semicolons aren't allowed.  Okay, your
assertion is true of "while label (expression)", if you omit "while"
it looks like a function call.  Big deal - *misspell* "while" and it
looks like a function call (I've done that, it compiled without a
whimper, good thing it didn't link - no lib function called "wihle").
Misspell "default" and it looks like a goto label (I HATE this -
there's NO diagnostic with any compiler I've used).

BTW misspell "return (value);" and it looks like a function call.
Misspell "return value;" and it looks like a syntax error.  :-)

>   a label. Major grief for the lexer/parser interface. So at a minmum
>   there should be a ':' after the label to help the lexer. If you
>   do that why not swap the order of the label and the for/while token
>   and do it like Java!

I don't know how Java does it.  Like this?

    inner: for (y = 0; y < MAXY; y++)

This is already a legal C construct, which makes "inner" a statement
label, which must make "goto inner" valid.  I don't want it to be
valid.

>3) It gains us virtually nothing. Remember we can't get rid of goto!
>   So we are introducing a new construct that duplicates things that
>   can be done with goto.

This is surely true, we can't make "goto" go away.  But I like
alternatives to "goto" that more directly express my intent.

Just last week I found a defective piece of code that avoided a goto
to leave a doubly-nested loop.  It broke the outer loop by
synthesizing it's exit condition, but it did it wrong.  I extracted
both loops into a separate static function, so that the inner loop
could break both loops with "return".  I was fortunate that these
loops' use of local variables was limited enough to make the
extraction viable.  I could have used "goto" but it's bad practice.

>The only benefit would be better error checking, because 'break <label>'

Bingo!  Better error checking is a useful goal, and a good enough
reason to add syntax.  Why else did ANSI introduce function
prototypes? C++ *needs* them to resolve overloaded functions.  C
doesn't *need* them but almost everyone agrees they were a worthwhile
addition.

>can be used in fewer situations than 'goto <label>'. But what sort of
>errors can we catch with this construct?

I've done enough assembly language programming to know the dangers of
misdirected goto's.

--
Richard Krehbiel, Kastle Systems, Arlington VA USA
rich@kastle.com (work) or richk@cais.com (personal)