|
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
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.