I would like to start the discussion (and process) of adding an INCLUDE instruction to Regina-Rexx. I initiated this topic as Support Request Item 950044.
I create numerous Rexx routines and over time have accumulated several procedures that are used over and over in each routine (for instance, tell me what OS I'm on, get me the system temporary directory name), and have accumulated these in a common file. So for each Rexx routine I write, I have to open the common file in my editor and copy the desired procedure(s) into the new routine.
Not only is this a hassle, it requires a flurry of fixes whenever an update to a common procedure is made (for instance, when Regina 3.4 started handling Windows Vista via uname()).
One could use a C preprocessor and simply insert the appropriate #include directives, but problems arise, e.g., when getting the line number, which will be different once the external procedure is inserted where the #include directive sits (i.e., the Rexx routine actually run looks different than that Rexx routine opened in an editor).
What Regina Rexx needs is some way to include common procedures similar to a preprocessor, have the interpreter update the source routine's content each time it is invoked, and perform the housekeeping necessary (e.g., tracking line numbers) for programmers to have accurate information.
I'm therefore proposing a Regina extension of the form,
When invoked, the INCLUDE statement would open the specified filename and write the procedure named 'label' found within the named file to the current Rexx routine.
If the 'label' portion is too code-intensive, I would be quite willing to have just
Regina would keep track of the number of lines entered and adjust, e.g., SIGL and sourceline() accordingly. There are probably other housekeeping tasks, but these are the two that immediately come to mind.
While I don't have the wherewithal to actually encode INCLUDE into Regina, I would be happy to lead the effort to prepare the spec (gathering user feedback, formally documenting, and coordinating discussions of "theory vs. reality" as must be done when a spec is turned into actual code).
Is there interest in this and someone who would be willing to head the development side of this effort?