REPEATPARMS Support for Repeating Prototype Parameters

Problem Statement

Today, RPG prototypes require every parameter to be explicitly declared. When interfacing with APIs that accept repeated name/value pairs or variable argument lists, developers must manually duplicate parameter definitions dozens or hundreds of times.

Example:

Dcl-Pr nox_Object pointer extproc(*CWIDEN : 'nox_Object');

   name00 Like(UTF8_1K) const options(*nopass:*varsize);
   valu00 pointer value options(*nopass:*string);

   name01 Like(UTF8_1K) const options(*nopass:*varsize);
   valu01 pointer value options(*nopass:*string);

   name02 Like(UTF8_1K) const options(*nopass:*varsize);
   valu02 pointer value options(*nopass:*string);

   // repeated many times...
End-Pr;

For APIs that support a large number of arguments, the prototype can become hundreds of lines long solely to accommodate optional repeated parameter pairs.

Requested Enhancement

Introduce a prototype keyword that allows a parameter (or parameter group) to be repeated automatically.

Example syntax:

Dcl-Pr nox_Object pointer extproc(*CWIDEN : 'nox_Object');

   name  Like(UTF8_1K) const
         options(*nopass:*varsize)
         repeatparms(*MAX);

   value pointer value
         options(*nopass:*string);

End-Pr;

or alternatively:

Dcl-Pr nox_Matrix pointer extproc(*CWIDEN : 'nox_Matrix');
   
   Matrix_Name Like(UTF8_1K) const options(*varsize);
 
   RepeatParms(10);
      name  Like(UTF8_1K) const options(*varsize);
      value pointer value options(*string);
   End-RepeatParms;   
   
   RepeatParms(*max);
      vectors pointer value;
   End-RepeatParms;

End-Pr;

Benefits

1. Improved interoperability with C APIs

Many C APIs use variadic arguments or repeated name/value pairs. RPG currently requires artificial prototype expansion to interface with such APIs. Native support would significantly simplify interoperability.

2. Reduced source code bloat

Large prototypes can contain hundreds of nearly identical parameter definitions. This negatively impacts readability, maintainability, and source size.

3. Better tooling support

Documentation generators such as ILEDocs must currently process and publish hundreds of duplicate parameter entries. A repeatable parameter definition would produce cleaner API documentation and metadata.

4. Easier API design

Library authors can expose flexible builder-style interfaces without generating excessive prototype definitions solely to satisfy compiler requirements.

5. Backward compatibility

This enhancement can be implemented as a new prototype keyword with no impact on existing RPG source code.

Example Use Case

The noxDB graph builder API allows callers to create JSON-like objects using repeated name/value pairs:

node = nox_Object(
   'name' : 'Scott' :
   'city' : 'Montreal' :
   'age'  : '42'
);

Today this requires manually defining dozens or hundreds of optional parameter pairs. With repeatable parameters, the prototype could accurately describe the interface while remaining concise and maintainable.