Re: FOR op-code

Tom wrote:
>I take your point about breaking existing FOR loops.  That would be bad.
>But as far as the syntax making it clear which direction to iterate....
The
>problem is that I must know *beforehand* which direction to loop and
commit
>that to code.  Maybe it's that (reaching way back) BASIC showing.  The
>increment variable should be evaluated once at the beginning of the loop.

Well, there are lot's of different ways to design a FOR loop.
Why did we do it that way?  I believe we wanted to provide an
upward compatible way to convert old-style iterative DO loops
to an expression-style syntax.  With DO loops, you can change
increment and limit values on the fly. You're right, probably
the better design would have the limit and increment computed
once at the beginning of the loop.

(Actually, FOR is almost completely upward compatible with the
DO opcode.  One remaining incompatibility should be eliminated
in the next release of the compiler.)

>An application for this that springs to mind is a READ/READP loop where I
>need to get, let's say, the next 10 records or the previous 10 records.
Say
>for a page-at-a-time SFL or something similar.

Well, since you have distinct READ and READP operations, you
still have to know the direction of the loop beforehand
anyways, right?

Cheers!  Hans

Hans Boldt, ILE RPG Development, IBM Toronto Lab, boldt@ca.ibm.com