Re: Choose between formal generic subprogram and subprogram access?

Re: Choose between formal generic subprogram and subprogram access?

[gautier_niouzes]

> What are the good rules how to choose between formal generic subprogram vs 
> subprogram access argument/discriminant/field?

If the subprogram is always needed, I opt for the generic way. There are some advantages:
- no access - don't need to worry about a possible null or bad access
- performance: if the subprogram is at the centre of an algorithm, it can be inlined and further optimized within the part of the program where the call is occurring. Of course the absence of access check and indirect call may help a bit.
_________________________ 
Gautier's Ada programming 
http://sf.net/users/gdemont/

Re: Choose between formal generic subprogram and subprogram access?

[Robert Eachus]

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."

Re: Choose between formal generic subprogram and subprogram access?

[Shark8]

On Wednesday, November 8, 2017 at 6:24:17 AM UTC-7, Victor Porton wrote:
> What are the good rules how to choose between formal generic subprogram vs 
> subprogram access argument/discriminant/field?

My personal rule on the matter is always use a generic, except when constraints are that you might-encounter/must-handle the case wherein there is no subprogram (the equivalent of null).

I like generics and, in general, think that they offer a lot of nice options -- especially when they can be parametrized on values/subprograms/generic-packages rather than as most popular languages have gone and just done type-parametrizations (eg "Integer_List List<Integer>" from Java, Delphi, C#, etc).