🚀 go-pugleaf

In article <47v1ja$k3d@natasha.rmii.com> jcoffin@rmii.com (Jerry Coffin) writes:
>erik@kroete2.freinet.de (Erik Corry) wrote:
>
>>Fredrik Bredberg (konfrbr@euax7i3c01.eua.ericsson.se) wrote:
>>What I think is wrong with 'named loops':
>>...
>>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.  

Maybe not for 'for's.  But I suspect Andrew was thinking of more
iteration and flow control statements.

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

Syntactically that's a solution (or rather wouldn't be ambiguous)
but it might be argued that it suffers from other problems (perhaps acceptable
ones though), the least that the label is elsewhere (it can be conversely
argued that the while in the do while is elsewhere too though).
Upon further investigation, it might be detected a more general ïsolution
is available.

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

I don't think that's what the suggestion was.  Anyway,
if allowing goto is indeed that horrible, perhaps named labels could
have the : before the label name, or if overloading tokens is so horrible,
pick a character that isn't used for anything.

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

Again, I don't believe that's what Fredrik(?) meant.

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

Although I agree some language rules should be for the compiler
writer, seems to me this point is mostly a quality of implementation issue.

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

Which implies (to me at least) possibility of more maintainable code too.

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

Certainly a grammar change only DOES NOT suffice for this proposal
(not saying you said it did,  I'm just pointing this out), so
although I'd like to think these were all true, wonder what impacts
it would really have upon deeper analysis.

- Greg
-- 
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
 Here:comeau@csanta.attmail.com / BIX:comeau or comeau@bix.com / CIS:72331,3421
    Voice:718-945-0009 / Fax:718-441-2310 / Prodigy: tshp50a / WELL: comeau