Local scope parameter for dow / dou ( perhaps for-each)

I don't expect that RPG will support lambda functions, nor iterators, however it will be easy for users to implement this kind of functionality if a local scopeed loop parameter could be provided by RPG to a user procedure. This will provide a better "separation of concerns" and make it possible to isolate user specific list iterations.

The idea is to create a parameter type - like any other except that it is only defined at the prototype for the procedure to be called. And if this "special" parameter is supplied it is maintained by RPG - allocated and initialized before the first iteration begins.

example:

// The prototype - note *scratchpad and inz

dcl-pr myIterator ind ;

counter int(10) options(*scratchpad) inz(0);

myText char(10) ;

end-pr;

dcl-s myReturnText char(10);

// Mainline - get all the text items from my iterator procedure.

// note the "counter" parameter is hidden by client code but provide by RPG

// and initialized by RPG before the invocation of the loop

dow myIterator (myReturnText);

dsply myReturnText;

enddo;

return;

dcl-proc myIterator;

dcl-pi *n ind;

counter int(10); // This is provided by RPG and is unique memory location for each dow/dou scope

myText char(10) ;

end-pi;

counter += 1;

myText = 'Loop ' + %char(counter);

return counter < 10;

end-proc;

Here I have just defined the hidden parameter in the prototype with option(*scratchpad) - I have no good name for it, but the "scratch pad" concept is also used in SQL UDTF.

The point here with the "scratch pad" idea, is that RPG will - before it enters the loop - provide a dynamic space of memory and initialize it so it is available for the implementation of the iterator procedure. Here I use an "int" but any RPG-native data type should be possible.

By providing a chunk of memory between the RPG code and the iterator code, then the implementation of the iterator code can be made in any other ILE language ( C, CPP , CLLE) and the implementation do not have to know about the mechanics for the RPG client code.

The idea here is to be able to encapsulate i.e. SQL open cursor initially, fetch rows for each successive call and finally close the cursor. Hide and isolate the iterator implementation that so it can be independently unittested.

Iterate through lists that is not arrays is also a use case. Arrays are nicely handled by "for-each". So perhaps this particular feature schuld rather be a part of user implementation in the "for-each" concept.

So what if the main loop in the client code returns within the loop? ( the control is not done by the iterator procedure) - Then RPG will call and run the "on-exit" part of (all active ) iterator implementation procedure(s) if provided. ( how to do that in plain C / CLLE i don't have figured out yet)

For simplicity - i did not provide the on-exit in this example. And this case does not requires explicit cleanup.

In the above example I have used a good old "Ind" as the return value. However, any return value ( bool, char ,int) that can be used in the logical comparison could of course be used.

The reason for the "dynamic and unique" is when this structure is used in a recursive loop / call