Instantiation of child generics?

Instantiation of child generics?

[Dale Stanbrough]

Hi,

I'ld like to create an abstract generic queue package with bounded
and unbounded children. However I have been thwarted in all attempts
to instantiate them. Also I don't really understand the rules for
instantiaion of child generics. Can anyone explain them?


e.g. 

	generic
		type element is private;
	package queues is 
		type queue is abstract tagged null record;
		
		procedure init return queue is abstract;
		
		procedure enqueue(item:in out queue; item:element) is abstract;

		-- etc
	end queues;
	
	
	generic
		size	:natural;
	package queues.bounded is
			
		type queue is new queues.queue with private;
		
		procedure init return queue is abstract;
		
		procedure enqueue(item:in out queue; item:element) is abstract;

	private
		type queue is new queues.queue with null record; -- for now...
	end;


How do I instantiate this?

	with queues.bounded;
	package myQ is new queues.bounded(integer, 5);
	
results in Gnat telling me "invalid prefix in selected component "queues""

Also will my (re)use of the identifier "queue" in the packages cause any
problems for me? It seems to compile ok, but i'm concerned that there might
be some nasty visibility issue lurking around the corner...

Thanks,

Dale

Re: Instantiation of child generics?

[Robert A Duff]

In article <4t9itp$imd@goanna.cs.rmit.edu.au>,
Dale Stanbrough  <dale@goanna.cs.rmit.edu.au> wrote:
>Hi,
>
>I'ld like to create an abstract generic queue package with bounded
>and unbounded children. However I have been thwarted in all attempts
>to instantiate them. Also I don't really understand the rules for
>instantiaion of child generics. Can anyone explain them?
>
>
>e.g. 
>
>	generic
>		type element is private;
>	package queues is 
>		type queue is abstract tagged null record;
>		
>		procedure init return queue is abstract;
>		
>		procedure enqueue(item:in out queue; item:element) is abstract;
>
>		-- etc
>	end queues;
>	
>	
>	generic
>		size	:natural;
>	package queues.bounded is
>			
>		type queue is new queues.queue with private;
>		
>		procedure init return queue is abstract;
>		
>		procedure enqueue(item:in out queue; item:element) is abstract;
>
>	private
>		type queue is new queues.queue with null record; -- for now...
>	end;
>
>
>How do I instantiate this?
>
>	with queues.bounded;
>	package myQ is new queues.bounded(integer, 5);

You need to instantiate the parent first:

    with queues;
    package integer_queues is new queus(element => integer);

Now, conceptually, for every child of queues, there is a generic child
of integer_queues.  But these are not visible unless you "with" the
corresponding child of queues.  Also, they are somewhat mythical -- the
compiler will normally not create them unless needed (now can it? -- it
can't know about all those children at compile time).

    with integer_queues;
    with queues.bounded; -- Makes Integer_Queues.Bounded visible.
    package bounded_integer_queues is new integer_queues.bounded(size => 5);

Or, you could make the instance a child:

    with integer_queues;
    with queues.bounded;
    package integer_queues.bounded_integer_queues is new
        integer_queues.bounded(size => 5);
    -- You can't call this instance integer_queues.bounded, because
    -- that's the name of a generic.

Or, you could nest them inside another package:

    with queues; -- Not strictly necessary, but I like to write this.
    with queues.bounded;
    package My_Queues is
        package int_queues is new queus(element => integer);
        -- Here, int_queues.bounded is visible, because queues.bounded
        -- is "with"ed, so we can instantiate it:
        package bounded is new int_queues.bounded(size => 5);
        ...
    end My_Queues;

>results in Gnat telling me "invalid prefix in selected component "queues""
>
>Also will my (re)use of the identifier "queue" in the packages cause any
>problems for me?

Should be OK, but I don't particularly like that style.

- Bob

Re: Instantiation of child generics?

[Tucker Taft]

Dale Stanbrough (dale@goanna.cs.rmit.edu.au) wrote:
: ... Also I don't really understand the rules for
: instantiaion of child generics. Can anyone explain them?

You should think of a child of a generic as a nested generic,
which is only visible to those who choose to mention it in a with clause.
Since it is conceptually a nested generic, you can only instantiate
it once you have already instantiated the enclosing generic.
Given your example below, you would first instantiate "queues":

   with queues;
   package queue_inst is new queues(Integer);

Then you would instantiate the "nested" generic "bounded" as follows:

   with queue_inst;  -- The instance of the enclosing generic
   with queues.bounded;  -- Makes the nested generic visible in all instances
   package bounded_inst is new queue_inst.bounded(200);

If "bounded" had been truly nested, rather than a child, the only difference
would be that you would omit the "with queues.bounded;"
The effect of "with queues.bounded;" is to "plug" the child "bounded"
into its parent generic "queues", meaning that "bounded" becomes visible
in all instances of "queues."

We struggled during the 9X process with children of generics, since
it is certainly a bit counterintuitive that you "with" "queues.bounded"
whereas you instantiate "queue_inst.bounded."  However, if you think
of a "with" clause as having the effect of "plugging" a child into
its parent unit, then you should be able to understand why children of
generics work the way they do.


: e.g. 

: 	generic
: 		type element is private;
: 	package queues is 
: 		type queue is abstract tagged null record;
: 		
: 		procedure init return queue is abstract;
: 		
: 		procedure enqueue(item:in out queue; item:element) is abstract;

: 		-- etc
: 	end queues;
: 	
: 	
: 	generic
: 		size	:natural;
: 	package queues.bounded is
: 			
: 		type queue is new queues.queue with private;
: 		
: 		procedure init return queue is abstract;
: 		
: 		procedure enqueue(item:in out queue; item:element) is abstract;

: 	private
: 		type queue is new queues.queue with null record; -- for now...
: 	end;


: How do I instantiate this?

: 	with queues.bounded;
: 	package myQ is new queues.bounded(integer, 5);
: 	
: results in Gnat telling me "invalid prefix in selected component "queues""

GNAT is correct; the prefix to "bounded" should be an instantiation
of queues, not queues itself.

: Also will my (re)use of the identifier "queue" in the packages cause any
: problems for me? It seems to compile ok, but i'm concerned that there might
: be some nasty visibility issue lurking around the corner...

Only if you "with" and "use" both packages.  Even then, you can still
use a full expanded name where there is a name conflict.

: Thanks,

: Dale

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Instantiation of child generics?

[Kevin J. Weise]

stt@henning.camb.inmet.com (Tucker Taft) wrote:
>Dale Stanbrough (dale@goanna.cs.rmit.edu.au) wrote:
>: ... Also I don't really understand the rules for
>: instantiaion of child generics. Can anyone explain them?
>
>You should think of a child of a generic as a nested generic,
>which is only visible to those who choose to mention it in a with clause.
>Since it is conceptually a nested generic, you can only instantiate
>it once you have already instantiated the enclosing generic.
   ...
>
>We struggled during the 9X process with children of generics, since
>it is certainly a bit counterintuitive that you "with" "queues.bounded"
>whereas you instantiate "queue_inst.bounded."  However, if you think
>of a "with" clause as having the effect of "plugging" a child into
>its parent unit, then you should be able to understand why children of
>generics work the way they do.
>

FWIW, Mr. Taft, I don't think it is counterintuitive at all.  If the effect 
is the same as if the child generic unit were nested within the parent 
generic unit, you would still follow the same process:  instantiate the 
parent first, then instantiate the child WRT the instance of the parent.

I think the Ada9X team did a great job on child units.

Now, if you want counterintuitive, I think there are some other areas that 
may qualify.  But they've probably already been hashed over & certainly 
belong in a different thread.

--------------------------------------------------------------------------
Kevin J. Weise              email:  kweise@sed.redstone.army.mil
COLSA Corp.                 voice:  (205) 842-9083
Huntsville, AL

.. standard disclaimers apply

Re: Instantiation of child generics?

[Robert A Duff]

In article <4taqvl$i11@michp1.redstone.army.mil>,
Kevin J. Weise <kweise@c3i-ccmail.sed.redstone.army.mil> wrote:
>FWIW, Mr. Taft, I don't think it is counterintuitive at all.  If the effect 
>is the same as if the child generic unit were nested within the parent 
>generic unit, you would still follow the same process:  instantiate the 
>parent first, then instantiate the child WRT the instance of the parent.

Yes, that all makes sense.  What is counter-intuitive is that you have
to say "with Parent_Generic.Child_Generic;".  Normally, you can't reach
into a generic and reference something inside it (you could never refer
to Generic_Package.Nested_Thing from outside).  This requires a special
visibility rule (see the last sentence of 10.1.6(2)).  And that "with"
magically makes Parent_Instance.Child_Generic visible.  I think that's
what Tucker meant by "counter-intuitive".  Once you've swallowed that
little oddity, everything makes sense -- instantiate the outer thing,
and then instantiate the Instance.inner-thing.

>I think the Ada9X team did a great job on child units.

The credit goes to Tucker and to Norman Cohen, who both apparently came
up with the same idea, somewhat independently.  (Tucker thought of it
all one night (he explained to me the next morning), and then realized
it was essentially the same as what Norman Cohen had proposed some
months earlier.)  The previous language definition was pretty hopeless,
actually.  Credit should also goes to the Swiss delegation to WG9, who
pushed the MRT into thinking about generic children in the first place.

>Now, if you want counterintuitive, I think there are some other areas that 
>may qualify.  But they've probably already been hashed over & certainly 
>belong in a different thread.

OK, I'm listening for different threads, with my language-designer hat
on.  ;-)

- Bob

Re: Instantiation of child generics?

[Dale Stanbrough]

Robert A Duff writes:

">Also will my (re)use of the identifier "queue" in the packages cause any
 >problems for me?
 
 Should be OK, but I don't particularly like that style."

...where the style is defining a type name in an "abstract" package,
and reusing the same name in concrete implementations in child packages.
(e.g. abstract type "queue", concrete bounded type "queue" and 
concrete unbounded type "queue"). The benefits are that (if you use use)
you can write your code

	myQ:queue;
	
and get diff. implementations by changing the with clause. What problems
do you forsee in doing this?

Dale

Re: Instantiation of child generics?

[Robert A Duff]

In article <4tkuv1$3jm@goanna.cs.rmit.edu.au>,
Dale Stanbrough  <dale@goanna.cs.rmit.EDU.AU> wrote:
>concrete unbounded type "queue"). The benefits are that (if you use use)
>you can write your code
>
>	myQ:queue;
>	
>and get diff. implementations by changing the with clause. What problems
>do you forsee in doing this?

Well, it's hardly a big deal, but I just don't like having zillions of
things called "queue".  It seems confusing.

Your "benefit" above only works if there is only one type of queue being
used in this module, by the way.

If I were using the style of calling all queue types "queue", I would
prefer to refer to Whatever_Pkg.Queue.  I really don't mind doing a
search-and-replace operation if I want to change what sort of queue it
is.  Emacs can search through multiple files, so it's not that hard.
And if you make a mistake, it will likely be detected at compile time.
You need to do that search anyway, just in case somebody used an
expanded name instead of a use_clause.

Finally, if you really want flexibility, you can use abstract class-wide
objects (or pointers to them), and try to localize the creation of
objects in a Factory package (which is often a good idea anyway).

Again, it's no big deal, either way.

- Bob