"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Adding the #for loop only solves the problem with a misplaced or missing
> increment statement, which is purely a programmer's error that can be largely
> avoided with a little diligence by the programmer.  Of course this is the type
> of infinite loop scenerio that the OP is referring to.
>
> This will not solve other infinite loop problems that are not related to
> programmer error such as conditional statements that are never satisfied due to
> some issue that is not superficially apparent.

Those, to, by definition are programmer errors, BTW.


> The #for loop would add some ease and conciseness to the coding end and help
> users avoid this programming error, but it would not add any functionality
> overall that isn't already achievable through a properly constructed #while
> loop.

*No* loop does. #while() is perfectly able to save it all, when properly
combined with #if() constructs.

Like with #for loops, the corresponding #while replacement may become
cumbersome, but it's perfectly possible.


> One further item on the potential creation of #for loops:  Would they be best
> end-bracketted with the general #end statement (as #while, #if, #switch and
> #macro all use)? Or would it be more appropriate to add a "#next" statement or
> even "#next n" statement instead?  #end would make it more consistent with
> current programming practice, but #next would make the #for loop construct more
> visible and identifiable.

Whith all other statements bracketed with #end, for consistency's sake there's
virtually no other way as to close them with #end, too. And why not?

Sure, a "#next i" statement helps identify the "#for" statement it belongs to,
but then again you can achieve the same through good indentation, or using
"#end // i".


> Along this line of thinking, perhaps more specific
> #end statements would also be more appropriate for the other situations as
> well: #while/#wend, #if/#endif, #switch/(#send?), #macro/(#mend?).  Of course
> you would likely keep the #end functionality for backwards compatibility.

I'd personally favor completely different bracketing rules anyways, using {}
instead (to use the same bracketing rules as for object statements, and
functions for that matter). Though I know various people (I don't dare make any
estimate here) would disagree.

I don't think a #wend, #send, #mend etc. is really necessary, and #endif would
make this inconsistent anyway.

If at all (there is a bit of a point here to identify the type of statement that
you expect to be ending, so as to enable the parser to better pin down where you
goofed the #end matching), I'd rather go for "#end if", "#end macro" etc.

Post a reply to this message