parameterless generics?

parameterless generics?

[Brian Gilbert]

Does anybody have a reason to use a generic (package or 
subprogram) without a parameter?  The language (Ada 83 at least) 
seems to allow it, but everytime the generic is instantiated it 
would produce an identical copy.  Comments?

Brian Gilbert
71413.1453@compuserve.com

Re: parameterless generics?

[Laurent Guerby]

Brian> Does anybody have a reason to use a generic (package or
Brian> subprogram) without a parameter?  The language (Ada 83 at
Brian> least) seems to allow it, but everytime the generic is
Brian> instantiated it would produce an identical copy.  Comments?
                                        ^^^^^^^^^^^^^^

   ... of the code, not of the variables:

generic 
package P is
   X : Integer;
end P;

with P;
package P1 is new P;

with P;
package P2 is new P;

   Now P1.X and P2.X are two differents variables.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: parameterless generics?

[Ray Blaak]

Brian Gilbert <71413.1453@CompuServe.COM> writes:

>Does anybody have a reason to use a generic (package or 
>subprogram) without a parameter?  The language (Ada 83 at least) 
>seems to allow it, but everytime the generic is instantiated it 
>would produce an identical copy.  Comments?

I find it useful primarily to give distinct types that cannot legally be
converted to each other.

generic
package Element is
  type Object is private;

  procedure Operation (On_The_Object : in out Object);
private
 type Object is ...;
end Element;

package Node is new Element;
package Symbol is new Element;

Node.Object and Symbol.Object cannot be converted from one to the other,
whereas they could if derived from a common type.

Another possible reason is to make functionality "active" only when you need
it. Consider:

package Entity is
  type Object is private;

  procedure Low_Impact_Operation (On_The_Object : in out Object);

  generic
  package Fancy_Processing_Involving_A_Huge_Link_Enclosure is
    procedure Do_It_At_Your_Own_Risk (To_Me : in out Object);
  end Fancy_Processing_Involving_A_Huge_Link_Enclosure;
end Entity;

It could be that one application (say offline report generation) only needs a
few features and a small link enclosure. The real system might be involved in a
complex architecture with a large link enclosure. By having the extra
operations in a generic, there should be no executable code generated for it
until instantiation. This would be dependent on how you wrote the generic and
how the compiler implements generics.

Cheers,
Ray Blaak
blaak@mda.ca

Re: parameterless generics?

[Mark A Biggar]

In article <4s4sns$nl4@map.mda.ca> blaak@mda.ca (Ray Blaak) writes:
>Brian Gilbert <71413.1453@CompuServe.COM> writes:
>>Does anybody have a reason to use a generic (package or 
>>subprogram) without a parameter?  The language (Ada 83 at least) 
>>seems to allow it, but everytime the generic is instantiated it 
>>would produce an identical copy.  Comments?

Generic Child Units in Ada95 will almost always be like this

>Another possible reason is to make functionality "active" only when you need
>it. Consider:
>
>package Entity is
>  type Object is private;
>
>  procedure Low_Impact_Operation (On_The_Object : in out Object);
>
>  generic
>  package Fancy_Processing_Involving_A_Huge_Link_Enclosure is
>    procedure Do_It_At_Your_Own_Risk (To_Me : in out Object);
>  end Fancy_Processing_Involving_A_Huge_Link_Enclosure;
>end Entity;
>It could be that one application (say offline report generation) only needs a
>few features and a small link enclosure. The real system might be involved in a
>complex architecture with a large link enclosure. By having the extra
>operations in a generic, there should be no executable code generated for it
>until instantiation. This would be dependent on how you wrote the generic and
>how the compiler implements generics.

This usage is of course complete subsumed by Child Packages.

--
Mark Biggar
mab@wdl.lmco.com

Re: parameterless generics?

[Philip Brashear]

In article <4s48k9$3be$1@mhafn.production.compuserve.com>,
Brian Gilbert  <71413.1453@CompuServe.COM> wrote:
>Does anybody have a reason to use a generic (package or 
>subprogram) without a parameter?  The language (Ada 83 at least) 
>seems to allow it, but everytime the generic is instantiated it 
>would produce an identical copy.  Comments?
>
>Brian Gilbert
>71413.1453@compuserve.com



Sure:

I've used a generic package to represent ONE OBJECT of an Abstract Data
Type (say Stack).  [But I also think that it would have been better to
use a generic type parameter so that I could have made stacks of XX.]

The idea is that the basic structure (the stack body) is in the package
body.  If your instantiation is called My_Stack, then you write calls
like "My_Stack.Push (Thing);", "if My_Stack.Is_Empty then", etc.  Some
people feel more comfortable with such syntax.

Anywho, it's an example.

Phil Brashear

Re: parameterless generics?

[Theodore E. Dennison]

Brian Gilbert wrote:
> 
> Does anybody have a reason to use a generic (package or
> subprogram) without a parameter?  The language (Ada 83 at least)
> seems to allow it, but everytime the generic is instantiated it
> would produce an identical copy.  Comments?

Well, you could do interesting things with a task declared in such
a generic...

It would also be good implementing "objects" using generic packages.
eg:
A program with several different random number generators, all using 
their own seeds.

There are possibilities.

-- 
T.E.D.          
                |  Work - mailto:dennison@escmail.orl.mmc.com  |
                |  Home - mailto:dennison@iag.net              |
                |  URL  - http://www.iag.net/~dennison         |

Re: parameterless generics?

[Robert Dewar]

Brian said

"Does anybody have a reason to use a generic (package or
subprogram) without a parameter?  The language (Ada 83 at least)
seems to allow it, but everytime the generic is instantiated it
would produce an identical copy.  Comments?
"

Such generics are often very useful, and very common in Ada code. You
missed one critical point. Each instantiation gets its own set of
package level variables.

For example a random number generic could read

generic
function random return float;

and each instance would have a separate seed

Re: parameterless generics?

[Mats Weber]

>Such generics are often very useful, and very common in Ada code. You
>missed one critical point. Each instantiation gets its own set of
>package level variables.
>
>For example a random number generic could read
>
>generic
>function random return float;
>
>and each instance would have a separate seed

I think you need a package to accomplish this.

Re: parameterless generics?

[Norman H. Cohen]

In article <4s48k9$3be$1@mhafn.production.compuserve.com>, Brian Gilbert
<71413.1453@CompuServe.COM> writes: 

|> Does anybody have a reason to use a generic (package or
|> subprogram) without a parameter?

Several people pointed out that each instance gets its own copies of
variables declared in the package, and someone pointed out that each
instantiation can initiate its own tasks.

In Ada 95, parameterless generics are useful as children of generic
packages.  Such children are themselves required to be generic (so that
the instantiation names a particular instance of the parent template, in
which the new instance of the child template will be logically nested).
However, it is typically not necessary to specify additional generic
parameters for the child.  For example: 

   generic
      type Element_Type is private;
      Capacity: in Positive;
   package Stacks is
      pragma Pure;
      type Stack_Type is private;
      procedure Push
         (Element: in Element_Type; Stack: in out Stack_Type);
      procedure Pop
         (Element: out Element_Type; Stack: in out Stack_Type);
      function Current_Size (Stack: Stack_Type) return Natural;
      Stack_Error: exception;
   private
      type Element_Array_Type is array (1 .. Capacity) of Element_Type;
      type Stack_Type is
         record
            Top      : Integer range 0 .. Capacity := 0;
            Elements : Element_Array_Type;
         end record;
   end Stacks;

   generic
   procedure Stacks.Make_Empty (Stack: out Stack_Type);
      -- This child of Stacks is a parameterless generic procedure

   procedure Stacks.Make_Empty (Stack: out Stack_Type) is
   begin
      Stack.Top := 0;
   end Stacks.Make_Empty;

   ----------------------------------------------------------------------

   with Ada.Strings.Unbounded, Stacks;
   package File_Name_Stacks is new Stacks
      (Ada.Strings.Unbounded.Unbounded_String, 1023);

       -- Within the scope of a with clause for Stacks.Make_Empty, the
       --   parent instance File_Name_Stacks can be viewed as logically
       --   containing a generic template named Make_Empty, in which
       --   global references to Stack_Type refer to
       --   File_Name_Stacks.Stack_Type.  (The child template does not
       --   contain any references to Element_Type, but if it did, they
       --   would refer to Unbounded_String.)

   with File_Name_Stacks, Stacks.Make_Empty;
   procedure Make_File_Name_Stack_Empty is
      new File_Name_Stacks.Make_Empty;

      -- This instantiates the generic template logically contained in
      --    File_Name_Stacks.

   ----------------------------------------------------------------------

   with Stacks;
   package Integer_Stacks is new Stacks (Integer, 8193);

       -- Within the scope of a with clause for Stacks.Make_Empty, the
       --   parent instance Integer_Stacks can be viewed as logically
       --   containing DIFFERENT a generic template named Make_Empty, in
       --   which global references to Stack_Type refer to
       --   Integer_Stacks.Stack_Type.  (If the child template had
       --   contained any references to Element_Type, they would refer to
       --   Integer.)

   with Integer_Stacks, Stacks.Make_Empty;
   procedure Make_Integer_Stack_Empty is
      new Integer_Stacks.Make_Empty;

      -- This instantiates the generic template logically contained in
      --    Integer_Stacks.


(See pages 731-732 of Ada as a Second Language for another example of a
parameterless generic used in this way.)

Of course a child of a generic is not PRECLUDED from having generic
parameters.   For example: 

   with Ada.Text_IO; use Ada.Text_IO;
   generic
      with procedure Dump_Element
         (File: in File_Type; Element: in Element_Type);
   procedure Stacks.Dump_Stack (File: in File_Type; Stack: in Stack_Type);

I've also seen unusual examples in which a generic package with an empty
visible part is instantiated to "install" something during the execution
of the initialization statements in the package body, but these examples
generally have generic parameters.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: parameterless generics?

[Chris Papademetrious]

Brian Gilbert <71413.1453@CompuServe.COM> wrote:

>Does anybody have a reason to use a generic (package or 
>subprogram) without a parameter?  The language (Ada 83 at least) 
>seems to allow it, but everytime the generic is instantiated it 
>would produce an identical copy.  Comments?

 I believe if you create a child library of a generic package (pardon
my butchering of the terminology, I'm new to Ada 95), the child itself
must also be generic.  Oftentimes, the child won't need a generic
parameter of its own, only needing that of its parent, in which case
you'd get the interesting construct:

generic
package Blah is...

 This is covered in "Programming in Ada 95" by John Barnes, page 390.

>Brian Gilbert
>71413.1453@compuserve.com


-=-=-=-=-=-=-=-=-=-=-=-=-
 Chris Papademetrious
 Data Fusion Laboratory
 Drexel University
 Philadelphia, PA
-=-=-=-=-=-=-=-=-=-=-=-=-

Re: parameterless generics?

[Richard Riehle]

On Mon, 15 Jul 1996, Chris Papademetrious wrote:

> Brian Gilbert <71413.1453@CompuServe.COM> wrote:
>
>  I believe if you create a child library of a generic package (pardon
> my butchering of the terminology, I'm new to Ada 95), the child itself
> must also be generic.  Oftentimes, the child won't need a generic
> parameter of its own, only needing that of its parent, in which case
> you'd get the interesting construct:
>
> generic
> package Blah is...
>
  If you think you are gong to need child units,  consider nesting the
  generic package inside a non-generic package.  Example:

     package Chopin is

       [ declare exportable services ]

           generic
             [ optional parameter list ]
           package Keyboard_Manager is
              [ declare exportable services ]
           end Keyboard_Manager;

       [ addtionally declared exportable services ]

     end Chopin;

  and then create children,

     package Chopin.Polonaise is ...

     package Chopin.Mazurka is ...

  and so on.

  I realize there are those who might object to this style, but there
  is actually precedent for it in Annex A of the (ISO 8652:1995)
  Ada Language Reference Manual.

  Richard Riehle
  AdaWorks Software Engineering
  Palo Alto, CA

Re: parameterless generics?

[Martin Lorentzon]

In article <4s48k9$3be$1@mhafn.production.compuserve.com>, Brian Gilbert
<71413.1453@CompuServe.COM> writes: 

|> Does anybody have a reason to use a generic (package or
|> subprogram) without a parameter?

How about getting the accessibility level right when extending tagged
types?

A small example:

======================================================================
-- This package is not generic because it needn't be.
package Foo is

   type Root is tagged null record;

end Foo;
======================================================================
-- This package needs to be generic for some reason.
with Foo;

generic
   type Element is private;

package Foobar is
   type Child is new Foo.Root with null record;
end Foobar;
======================================================================
-- Now we can't instansitate the foobar package. 
-- Compiling the `bar' procedure is an error:
with Foo;
with Foobar;
procedure Bar is 

   package Fb is new Foobar(Float);

begin
   null;
end Bar;
======================================================================
Rewriting the `Foo' package as a generic package solves the problem:
======================================================================
-- Now the package Foo is generic and takes no parameters. It's
-- generic only to used as a parameter to foobar:
generic
package Foo is

   type Root is tagged null record;

end Foo;
======================================================================
-- Package Foobar now takes an instantiation of package Foo as a
-- generic parameter to avoid getting the type extension at a deeper
-- accessibility level than the parent:
with Foo;

generic
   type Element is private;
   with package Foo_Inst is new Foo;
package Foobar is
   type Child is new Foo_Inst.Root with null record;
end Foobar;
======================================================================
-- Finally we let the `Bar' procedure take care of the instantiations:
with Foo;
with Foobar;
procedure Bar is 

   package F is new Foo;
   package Fb is new Foobar(Float,F);

begin
   null;
end Bar;


-- Regards,
--		Martin.