Re: Choose between formal generic subprogram and subprogram access?

[Robert Eachus <rieachus@comcast.net>]

On Wednesday, November 8, 2017 at 8:24:17 AM UTC-5, Victor Porton wrote:
> What are the good rules how to choose between formal generic subprogram vs 
> subprogram access argument/discriminant/field?
> 
Generics give you a way to divide the arguments to a routine into those which are determined early, and those that vary with each call.

For example, you might have a routine for "pretty" printing block comments.  It would need to know the (output) line length, how much to indent the block, and of course, the source to reformat.

The line length feels right as a generic parameter.  The source to reformat should definitely be a formal parameter, and the indentation is your call.  What if the routine is expected to read from a source file, and stop at the next non-comment line?  Now the file name looks like a generic formal, probably along with a position in the file.  But it is interesting to notice here that how the (Ada) implementation handles line numbering may affect  your decision.

The underlying idiom here is that there are three places where a generic subprogram can find input data: Generic formal parameters, variables (and constants) in the enclosing (generic) packages, and regular formal parameters.  It helps the programmer using the generic unit or package if the values needed for a call are arranged such that values in the package have defaults and are least likely to be changed, while the programmer needs to think about the non-generic formal parameters whenever he writes a call.

There is also a fourth place, in the body of the main program. The Ada/SIL compiler I worked on at Honeywell started out as an extension of Green for systems implementation purposes.  So we put lots of effort into creating optimal OS code.  One long running discussion was whether to have a display, or to walk the stack.  Obviously accessing the current stack frame (and any frames merged with it by the optimizer) and the main program body plus variables and constants in library level packages.

Eventually I put code in where the stack walk would be to e-mail me the code that called it.*  I never got any e-mails, so the code never got written. ;-)  Along the way though, I collected statistics on how many variable references went to the main program, to library packages, to generic formals, and to local variables.  There were some fun things too, since this was Multics, I could have statistics collected on all uses of the compiler.  Use of variables in the main program dropped rapidly as programmers used the compiler, and use/set for generic formals was close to one.

Does this give you a feel for "the Ada way" to write code?  The main program  is short, often shorter than its context clauses.  Code in library and generic packages has generic parameters that are not used much, the rest is variables in packages or in the local subroutine that is doing the work.  There are lots of "wrapper" routines with only a few lines that either set or return the value of a variable not visible to the user of the package, and a few large tasks or procedures that do all the work.

* This sort of thing was common in compilers--and other system software--on Multics.  I, or any maintainer, could edit the compiler code, recompile it, and continue the compiler from the point where it had paused to send the e-mail, I had 90 seconds from the e-mail being sent to tell the compiler to stay paused--oh and send the user involved a message saying "Please wait, the compiler is being upgraded."  Otherwise the message was: "Code generation error, unimplemented feature xx-xxxx."