Instantiations of a generic with often encountered arguments

Instantiations of a generic with often encountered arguments

[Victor Porton]

Is it a good practice to declare "centralized" (that is in the same package 
as a generic packages is defined in, or in a child unit) instantiations of a 
generic package with common (that is often encountered, such as Integer, 
String, etc.) generic parameters?

In C++ this is not a problem, because there a template is instantiated 
whenever one needs it. But what's about Ada?

-- 
Victor Porton - http://portonvictor.org

Re: Instantiations of a generic with often encountered arguments

[gautier_niouzes]

You may want to put your instantiations in the narrowest scope you need it - could be in a loop, or within another generic... with nesting, the possibilities are infinite! Sometimes a generic itself is very local, so the instantiations happen to be right after the generic body (the generic spec, body and instanciations could be all within a loop for instance).

Re: Instantiations of a generic with often encountered arguments

[Dmitry A. Kazakov]

On 2017-11-26 01:04, Victor Porton wrote:
> Is it a good practice to declare "centralized" (that is in the same package
> as a generic packages is defined in, or in a child unit) instantiations of a
> generic package with common (that is often encountered, such as Integer,
> String, etc.) generic parameters?

Yes, Ada library does so for standard types.

Sometimes a set of related generic packages is instantiated in a third 
package which is then used. E.g. you have a generic vector, matrix, 
solver defined over the same type.

> In C++ this is not a problem, because there a template is instantiated
> whenever one needs it.

Because in C++ templates are 100% macros, whereas in Ada generic 
instances can be shared, theoretically at least, and should be treated 
as real packages.

Then C++ templates have structrual matching, all instances/expansions 
with same parameters are same. It is no matter where you would expand a 
macro. Ada uses nominal matching of generic instances and they can be 
scoped.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Instantiations of a generic with often encountered arguments

[Victor Porton]

Dmitry A. Kazakov wrote:

> On 2017-11-26 01:04, Victor Porton wrote:
>> Is it a good practice to declare "centralized" (that is in the same
>> package as a generic packages is defined in, or in a child unit)
>> instantiations of a generic package with common (that is often
>> encountered, such as Integer, String, etc.) generic parameters?
> 
> Yes, Ada library does so for standard types.

Where?!

> Sometimes a set of related generic packages is instantiated in a third
> package which is then used. E.g. you have a generic vector, matrix,
> solver defined over the same type.
> 
>> In C++ this is not a problem, because there a template is instantiated
>> whenever one needs it.
> 
> Because in C++ templates are 100% macros, whereas in Ada generic
> instances can be shared, theoretically at least, and should be treated
> as real packages.
> 
> Then C++ templates have structrual matching, all instances/expansions
> with same parameters are same. It is no matter where you would expand a
> macro. Ada uses nominal matching of generic instances and they can be
> scoped.

I received what seems two opposite opinions on my question.

Please state the reasons.

I am now in analysis-paralysis of whether to define instantiations for often 
encountered types in advance (globally) or immediately before use.

-- 
Victor Porton - http://portonvictor.org

Re: Instantiations of a generic with often encountered arguments

[Simon Wright]

Victor Porton <porton@narod.ru> writes:
> Dmitry A. Kazakov wrote:
>
>> On 2017-11-26 01:04, Victor Porton wrote:
>>> Is it a good practice to declare "centralized" (that is in the same
>>> package as a generic packages is defined in, or in a child unit)
>>> instantiations of a generic package with common (that is often
>>> encountered, such as Integer, String, etc.) generic parameters?
>> 
>> Yes, Ada library does so for standard types.
>
> Where?!

e.g.

   with Ada.Numerics.Generic_Elementary_Functions;

   package Ada.Numerics.Elementary_Functions is
     new Ada.Numerics.Generic_Elementary_Functions (Float);

   pragma Pure (Elementary_Functions);

Re: Instantiations of a generic with often encountered arguments

[Dmitry A. Kazakov]

On 27/11/2017 03:02, Victor Porton wrote:

> I received what seems two opposite opinions on my question.

Opinions meant to be different...

> Please state the reasons.
> 
> I am now in analysis-paralysis of whether to define instantiations for often
> encountered types in advance (globally) or immediately before use.

The latter is C++ policy which is acceptable because in C++ there is no 
lingering effects of an act of instantiation. Therefore C++ can deploy 
automatic instantiation and need not to care how frequently you do so. 
In Ada instantiation has consequences. Consider:

generic
    ...
package Printer is
    procedure Print (Text : String);
private
    task Monitor is
       entry Do_Print (Text : String);
    end Monitor;
end Printer;

Each instance produces a new task.

"Don't multiply entities beyond necessity"

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Instantiations of a generic with often encountered arguments

[Shark8]

On Sunday, November 26, 2017 at 7:02:23 PM UTC-7, Victor Porton wrote:
> 
> I am now in analysis-paralysis of whether to define instantiations for often 
> encountered types in advance (globally) or immediately before use.

Ok, I completely understand that problem -- the right way will undoubtedly influence your codebase and you don't want to have to rewrite everything.

Unfortunately I can't give you a hard rule on how you should proceed because, like so many other things, it depends on what you're doing. (e.g. do you want to make SOME_TYPE limited & private, just private, just limited, or neither? It really depends, if you're passing around a handle where there's some sort of reference-counting going on, you'll want limited private to ensure that you're not accidentally mucking about on the internal count. OTOH, if you're implementing a parallel solver, you probably want your data non-limited so you can copy it and feed these copies to your worker-tasks freely.)

For generics, I've found that making a "global instantiation" generic is best when you're either (a) working on an entire [sub-]system that is generic [e.g. a parser that you're going to use multiple times with different syntax-sets] or (b) when the functions themselves are anticipated to be used widely in your code [e.g. the Ada.Numerics.Elementary_Functions example].

One last option is leveraging Ada's visibility/scoping rules to "mix and match" your options; example you have a generic package GENERIC_AUDIO_OPERATIONS containing subprograms that are going to be used all over the audio portion of an application:

With
Application.Generics.GENERIC_AUDIO_OPERATIONS;

Package Application.Subsystems.Audio is

Private
  Package Operations is New GENERIC_AUDIO_OPERATIONS( [[parameters]] );
  Use Operations;
  -- The instantiation is now directly visible/usable to the private and
  -- (IIRC) implementation portions of child packages.
End Application.Subsystems.Audio;