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

Hmm...subjective, but it doesn't look particularly hard to parse to me.

>2) It's a completely new syntax for C. This makes parsing it difficult.
>   Specifically it looks like a function call inner() yet it is actually
>   a label. Major grief for the lexer/parser interface.

Not at all.  To the lexer, we simply have an identifier like any other.
To the parser we have something like this:

for_loop:		"for" "(" <for_control> ")" <expr>
		|	"for" <identifier> "(" <for_control> ")" <expr>

and no ambiguity is introduced.  A while loop would be similar, as once
again, there's no legal use of a function call betwen the "while" and
the condition.  

Introducing the same thing for do loops would be more problematic, as
the "do" is not followed by a condition, but by an expression, so the
identifier would simply be part of a normal expression.  One obvious
cure would be to require that the name continue to go with the closing
'while' of the loop, again placed between the keyword and the condition,
where it remains unambiguous.

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

This would render the name of the loop syntactically identical to any
other label, and thus a legal target of a goto as well as the named
break statement.  IMO, that's a poor idea.

This could also reduce possibilities for optimization in some compilers.
Most optimizers can determine which labels are actually used, and
optimize accordingly, but others treat any legal label as a possible
target of a jump, which reduces the posibility of optimizations that
merge what's before the jump with what follows the jump.

I'll openly admit that's a relatively weak argument, but at the same
time I don't see much sense in introducing a construct that we're aware
ahead of time is likely to reduce optimization unless it has advantages
to override that minor shortcoming.

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

Other examples of such constructs include 'for', 'while', 'do' and
'switch'.  Examples of languages devoid of such duplication are largely
restricted to such things as FORTRAN 66 and early BASIC interpeters.

One can produce flow control of arbitrary complexity with no constructs
other than 'if' and 'goto', but this lack of constraint on 'goto' is
generally a weakness rather than a strength.

>The only benefit would be better error checking, because 'break <label>'
>can be used in fewer situations than 'goto <label>'. But what sort of
>errors can we catch with this construct?

I'd consider improvements in readability beneficial.  The proposed
construct is more constrained than a goto, about which see above.

>1) Do it like Java.
>2) Leave it as it is.

If either of these is considered a constraint on C9x, then there's no
reason to even work on C9x as it'll just 1) standardize Java as C or 2)
standardize C90 as C9x.  Therefore, I'd introduce the following third
possibility:

3) Do it better than it currently is, or than Java does it.

I think this proposal is exactly the sort of thing that should be
considered for inclusion in C9x:
1) It doesn't add substantially to the "size" of the language.
2) To the extent that modifying a parser can be legal, this is.
3) It has no effect on any currently legal code.
    Later,
    Jerry.

/* I can barely express my own opinions; I certainly can't
 * express anybody else's.
 *
 * The universe is a figment of its own imagination.
 */