generics in Ada 83

generics in Ada 83

[REH]

Is there a way to define a default for the with'd procedure in the
following example in Ada 83:

generic
    type X is private;
    with procedure Y(Z : in X);
package Foo;

I want to define a default for Y, but how can I without knowing X?

I have a generic package that has several with'd procedures, but
depending on what services the package provides are use, only a few of
the procedures may need to be defined.  I'd like to just default the
unused ones to stubs.

Thanks.

Re: generics in Ada 83

[Georg Bauhaus]

REH wrote:

> generic
>     type X is private;
>     with procedure Y(Z : in X);
> package Foo;
> 
> I want to define a default for Y, but how can I without knowing X?

Can you make generic stubs?

Re: generics in Ada 83

[REH]

Georg Bauhaus wrote:
> REH wrote:
>
> > generic
> >     type X is private;
> >     with procedure Y(Z : in X);
> > package Foo;
> >
> > I want to define a default for Y, but how can I without knowing X?
>
> Can you make generic stubs?

Can you do that in '83?  I tried but I kept getting compiler errors.

Re: generics in Ada 83

[Georg Bauhaus]

REH wrote:
> Georg Bauhaus wrote:
> 
>>REH wrote:
>>
>>
>>>generic
>>>    type X is private;
>>>    with procedure Y(Z : in X);
>>>package Foo;
>>>
>>>I want to define a default for Y, but how can I without knowing X?
>>
>>Can you make generic stubs?
> 
> 
> Can you do that in '83?  I tried but I kept getting compiler errors.
> 

Something like this may work. Unless I misunderstand your problem, i.e..
The generic package Stubs.X_Operations provides default null procedures
for any private type X. You can use these operations as default
values when instantiating Foo.

generic
   type X is private;
   with procedure Y(Z : in X) is <>;
   -- lots of others
package Foo is end Foo;


with Stubs;
with Foo;

package Op_Maker is


   type Some_Type is record
      data: Natural;
   end record;

   type Some_Other_Type is record
      data: Character;
   end record;

   package Some_Operations is
      new Stubs.X_Operations(X => Some_Type);

   package Some_More_Operations is
      new Stubs.X_Operations(X => Some_Other_Type);

   use Some_Operations, Some_More_Operations;

   package A_Foo is new Foo(Some_Type);
   package Another_Foo is new Foo(Some_Other_Type);

end Op_Maker;

package Stubs is

   generic
      type X is private;
   package X_Operations is

      -- null procedures

      procedure Y(Z: in X);
      procedure Y2(U, V: in X);

   end X_Operations;

end Stubs;

package body Stubs is

   package body X_Operations is

      procedure Y(Z: in X) is
      begin null;
      end Y;

      procedure Y2(U, V: in X) is
      begin null;
      end Y2;

   end X_Operations;

end Stubs;

Re: generics in Ada 83

[Martin Dowie]

REH wrote:
> Is there a way to define a default for the with'd procedure in the
> following example in Ada 83:
>
> generic
>     type X is private;
>     with procedure Y(Z : in X);
> package Foo;
>
> I want to define a default for Y, but how can I without knowing X?
>
> I have a generic package that has several with'd procedures, but
> depending on what services the package provides are use, only a few of
> the procedures may need to be defined.  I'd like to just default the
> unused ones to stubs.

Same as Ada95:

generic
   type X is private;
   with procedure Y (Z : X) is <>;
package Foo is
end Foo;

Or do you mean you want the compiler to magically insert a 'null' procedure
if there isn't a matching procedure Y for whatever type X happens to be? If
that's the case you can't do that. There has to be some procedure (even one
that's only 'begin null end;') for each type.

Cheers

-- Martin

Re: generics in Ada 83

[REH]

Martin Dowie wrote:
> REH wrote:
> > Is there a way to define a default for the with'd procedure in the
> > following example in Ada 83:
> >
> > generic
> >     type X is private;
> >     with procedure Y(Z : in X);
> > package Foo;
> >
> > I want to define a default for Y, but how can I without knowing X?
> >
> > I have a generic package that has several with'd procedures, but
> > depending on what services the package provides are use, only a few of
> > the procedures may need to be defined.  I'd like to just default the
> > unused ones to stubs.
>
> Same as Ada95:
>
> generic
>    type X is private;
>    with procedure Y (Z : X) is <>;
> package Foo is
> end Foo;
>
> Or do you mean you want the compiler to magically insert a 'null' procedure
> if there isn't a matching procedure Y for whatever type X happens to be? If
> that's the case you can't do that. There has to be some procedure (even one
> that's only 'begin null end;') for each type.
>
> Cheers
>
> -- Martin

defining it with a box won't work.  There would have to a procedure
already defined.  What I want is something like:

generic
    type X is private;
    with procedure Y(Z : in X) is P;
package Foo


but of course P must already take into account X.  With '95 I think I
could just with a generic package containing the stubs, but I can
figure out a way in '83.

Thanks.

Re: generics in Ada 83

[Martin Dowie]

REH wrote:
> Martin Dowie wrote:
> 
>>REH wrote:
>>
>>>Is there a way to define a default for the with'd procedure in the
>>>following example in Ada 83:
>>>
>>>generic
>>>    type X is private;
>>>    with procedure Y(Z : in X);
>>>package Foo;
>>>
>>>I want to define a default for Y, but how can I without knowing X?
>>>
>>>I have a generic package that has several with'd procedures, but
>>>depending on what services the package provides are use, only a few of
>>>the procedures may need to be defined.  I'd like to just default the
>>>unused ones to stubs.
>>
>>Same as Ada95:
>>
>>generic
>>   type X is private;
>>   with procedure Y (Z : X) is <>;
>>package Foo is
>>end Foo;
>>
>>Or do you mean you want the compiler to magically insert a 'null' procedure
>>if there isn't a matching procedure Y for whatever type X happens to be? If
>>that's the case you can't do that. There has to be some procedure (even one
>>that's only 'begin null end;') for each type.
>>
>>Cheers
>>
>>-- Martin
> 
> 
> defining it with a box won't work.  There would have to a procedure
> already defined.  What I want is something like:
> 
> generic
>     type X is private;
>     with procedure Y(Z : in X) is P;
> package Foo
> 
> 
> but of course P must already take into account X.  With '95 I think I
> could just with a generic package containing the stubs, but I can
> figure out a way in '83.

Yes, how can you have 'P' know which X?

The best I can see is:

package A is
    type A_T is private;
    procedure Y (Z : A_T);
private
    type A_T is new Integer;
end A;

generic
    type X is private;
    with procedure Y (Z : X) is <>;
package B is
end B;

with A; use A;
with B;

package C is
    new B (A_T);  -- Picks up 'Y' by default

Cheers

-- Martin

Re: generics in Ada 83

[REH]

Martin Dowie wrote:
> REH wrote:
> > Martin Dowie wrote:
> >
> >>REH wrote:
> >>
> >>>Is there a way to define a default for the with'd procedure in the
> >>>following example in Ada 83:
> >>>
> >>>generic
> >>>    type X is private;
> >>>    with procedure Y(Z : in X);
> >>>package Foo;
> >>>
> >>>I want to define a default for Y, but how can I without knowing X?
> >>>
> >>>I have a generic package that has several with'd procedures, but
> >>>depending on what services the package provides are use, only a few of
> >>>the procedures may need to be defined.  I'd like to just default the
> >>>unused ones to stubs.
> >>
> >>Same as Ada95:
> >>
> >>generic
> >>   type X is private;
> >>   with procedure Y (Z : X) is <>;
> >>package Foo is
> >>end Foo;
> >>
> >>Or do you mean you want the compiler to magically insert a 'null' procedure
> >>if there isn't a matching procedure Y for whatever type X happens to be? If
> >>that's the case you can't do that. There has to be some procedure (even one
> >>that's only 'begin null end;') for each type.
> >>
> >>Cheers
> >>
> >>-- Martin
> >
> >
> > defining it with a box won't work.  There would have to a procedure
> > already defined.  What I want is something like:
> >
> > generic
> >     type X is private;
> >     with procedure Y(Z : in X) is P;
> > package Foo
> >
> >
> > but of course P must already take into account X.  With '95 I think I
> > could just with a generic package containing the stubs, but I can
> > figure out a way in '83.
>
> Yes, how can you have 'P' know which X?
>
> The best I can see is:
>
> package A is
>     type A_T is private;
>     procedure Y (Z : A_T);
> private
>     type A_T is new Integer;
> end A;
>
> generic
>     type X is private;
>     with procedure Y (Z : X) is <>;
> package B is
> end B;
>
> with A; use A;
> with B;
>
> package C is
>     new B (A_T);  -- Picks up 'Y' by default
>
> Cheers
>
> -- Martin

That seems reasonable.  Two questions:
1) If I have Y1 through Yn, Do I define the ones I care about when I
instantiate B or do I define then in C, before B?
2) is there a way to avoid having to include A?

Re: generics in Ada 83

[Ludovic Brenta]

"REH" <spamjunk@stny.rr.com> writes:
> Martin Dowie wrote:
>> package A is
>>     type A_T is private;
>>     procedure Y (Z : A_T);
>> private
>>     type A_T is new Integer;
>> end A;
>>
>> generic
>>     type X is private;
>>     with procedure Y (Z : X) is <>;
>> package B is
>> end B;
>>
>> with A; use A;
>> with B;
>>
>> package C is
>>     new B (A_T);  -- Picks up 'Y' by default
>>
>> Cheers
>>
>> -- Martin
>
> That seems reasonable.  Two questions:
> 1) If I have Y1 through Yn, Do I define the ones I care about when I
> instantiate B or do I define then in C, before B?

If there are several Y's to choose from, you must choose at the point
of instantiation of B:

with A, B;
package C is new B (X => A.A_T, Y => A.Yn);

> 2) is there a way to avoid having to include A?

C must see the type and procedure passed to it as actual generic
parameters, so there I can think of no way to avoid withing A.

-- 
Ludovic Brenta.

Re: generics in Ada 83

[REH]

Ludovic Brenta wrote:
> "REH" <spamjunk@stny.rr.com> writes:
> > Martin Dowie wrote:
> >> package A is
> >>     type A_T is private;
> >>     procedure Y (Z : A_T);
> >> private
> >>     type A_T is new Integer;
> >> end A;
> >>
> >> generic
> >>     type X is private;
> >>     with procedure Y (Z : X) is <>;
> >> package B is
> >> end B;
> >>
> >> with A; use A;
> >> with B;
> >>
> >> package C is
> >>     new B (A_T);  -- Picks up 'Y' by default
> >>
> >> Cheers
> >>
> >> -- Martin
> >
> > That seems reasonable.  Two questions:
> > 1) If I have Y1 through Yn, Do I define the ones I care about when I
> > instantiate B or do I define then in C, before B?
>
> If there are several Y's to choose from, you must choose at the point
> of instantiation of B:
>
> with A, B;
> package C is new B (X => A.A_T, Y => A.Yn);
>
I'm sorry.  I was not clear.  I meant several Y's to define, but I only
want to define some.  My understanding is I need to instantiate the
ones I care about in C, and the rest will receive the stubs from A.  Is
that correct?

with A, B, D;
package C is new B (X => A.A_T, Y1 => D.Y1, Y3 => D.Y3);

So, if I define things correctly, Y2 will default to A.Y2?

Re: generics in Ada 83

[Jeffrey Carter]

REH wrote:
> 
> generic
>     type X is private;
>     with procedure Y(Z : in X);
> package Foo;
> 
> I want to define a default for Y, but how can I without knowing X?

Defaults are defined for subprograms by inserting "is Name" or "is <>" 
before the semicolon (;):

    with procedure Y (Z : in X) is A;

or

    with procedure Y (Z : in X) is <>;

You can't use the former, since it requires a procedure A, visible at 
the point of the generic, that matches Y. Since you don't know what X is 
at the point of the generic, you can't have such a procedure.

You can use the latter, which requires a procedure Y, visible at the 
point of the instantiation. However, that's unlikely to be what you want.

You can also use a 2-step instantiation:

generic -- Outer
    type X is private;
package Outer is
    procedure Null_Proc (Z : in X);

    generic -- Inner
       with procedure Y (Z : in X) is Null_Proc;
    package Inner is
       ...
    end Inner;
end Outer;

Such an approach complicates the process of instantiating the generic, 
but may be OK if it results in an overall reduction in the complexity of 
the instantiation process. If your generic has many formal subprograms, 
but only a small percentage are likely to need explicit actuals, this 
might be acceptable.

However, if it's unlikely that a client will use all the services of the 
package, and different clients will use different subsets of those 
services, then you probably have a design problem. In such a case, you 
probably want to redesign to have several packages that factor out the 
likely subsets: several generics that provide the non-overlapping 
subsets of the possible services, and perhaps some higher-level generics 
that instantiate 2 or more of the non-overlapping subsets to provide 
overlapping subsets.

-- 
Jeffrey Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail
E-mail: jeffrey_r_carter-nr [commercial-at]
         raytheon [period | full stop] com

Re: generics in Ada 83

[REH]

Jeffrey Carter wrote:
> REH wrote:
> >
> > generic
> >     type X is private;
> >     with procedure Y(Z : in X);
> > package Foo;
> >
> > I want to define a default for Y, but how can I without knowing X?
>
> Defaults are defined for subprograms by inserting "is Name" or "is <>"
> before the semicolon (;):
>
>     with procedure Y (Z : in X) is A;
>
> or
>
>     with procedure Y (Z : in X) is <>;
>
> You can't use the former, since it requires a procedure A, visible at
> the point of the generic, that matches Y. Since you don't know what X is
> at the point of the generic, you can't have such a procedure.
>
> You can use the latter, which requires a procedure Y, visible at the
> point of the instantiation. However, that's unlikely to be what you want.
>
> You can also use a 2-step instantiation:
>
> generic -- Outer
>     type X is private;
> package Outer is
>     procedure Null_Proc (Z : in X);
>
>     generic -- Inner
>        with procedure Y (Z : in X) is Null_Proc;
>     package Inner is
>        ...
>     end Inner;
> end Outer;
>
> Such an approach complicates the process of instantiating the generic,
> but may be OK if it results in an overall reduction in the complexity of
> the instantiation process. If your generic has many formal subprograms,
> but only a small percentage are likely to need explicit actuals, this
> might be acceptable.
>
> However, if it's unlikely that a client will use all the services of the
> package, and different clients will use different subsets of those
> services, then you probably have a design problem. In such a case, you
> probably want to redesign to have several packages that factor out the
> likely subsets: several generics that provide the non-overlapping
> subsets of the possible services, and perhaps some higher-level generics
> that instantiate 2 or more of the non-overlapping subsets to provide
> overlapping subsets.
>
Well I guess there is always a better way.  Here is my actual problem.
My team maintains a set of middleware services for various
applications.  We have a Client/Server package as part of this.  It
defines a header type for transmitting messages across TCP/IP.  One
application group has requested the ability to define their own header.
 There are certain pieces of information our software needs to know
from the header, such as the message length.  So I re-defined the
package thus:

generic
    type Header_Type is private;

    with function Get_Length(Header : in Header_Type) return Integer;

    with procedure Set_Length(Header : in out Header_Type;
                              Length : in Integer);
package Client_Server;

This works fine for using most of the services in the package.  But the
thorn is the package provides a "synchronous send" feature that does a
request/response type of transaction over a network.  This requires
several more fields to be present in the header and accessed at various
times.  Thus, I have added get and set subprograms for those.  But I
don't want a client application that does not use this feature to have
to define stubs for all these.  Which is where I am tried to find a way
to "default" them.

Thanks for your time and help.

REH

Re: generics in Ada 83

[Jeffrey Carter]

REH wrote:
> 
> Well I guess there is always a better way.  Here is my actual problem.
> My team maintains a set of middleware services for various
> applications.  We have a Client/Server package as part of this.  It
> defines a header type for transmitting messages across TCP/IP.  One
> application group has requested the ability to define their own header.
>  There are certain pieces of information our software needs to know
> from the header, such as the message length.  So I re-defined the
> package thus:
> 
> generic
>     type Header_Type is private;
> 
>     with function Get_Length(Header : in Header_Type) return Integer;
> 
>     with procedure Set_Length(Header : in out Header_Type;
>                               Length : in Integer);
> package Client_Server;
> 
> This works fine for using most of the services in the package.  But the
> thorn is the package provides a "synchronous send" feature that does a
> request/response type of transaction over a network.  This requires
> several more fields to be present in the header and accessed at various
> times.  Thus, I have added get and set subprograms for those.  But I
> don't want a client application that does not use this feature to have
> to define stubs for all these.  Which is where I am tried to find a way
> to "default" them.

Then you're in good shape. 1st, define your complete generic for using 
the synchronous send feature:

generic -- Client_Server_With_Synchronous_Send
    type Header_Type is private;

    -- many formal subprograms
package Client_Server_With_Synchronous_Send is
    procedure Op (Header : in out Header_Type);

    ...
end Client_Server_With_Synchronous_Send;

then define your shorter generic:

generic -- Client_Server
    type Header_Type is private;

    with function Get_Length(Header : in Header_Type) return Integer;

    with procedure Set_Length(Header : in out Header_Type;
                              Length : in Integer);
package Client_Server is
    -- presumably a smaller set of operations than
    -- Client_Server_With_Synchronous_Send
    procedure Op (Header : in out Header_Type);

    ...
end Client_Server;

Now, the body of Client_Server instantiates 
Client_Server_With_Synchronous_Send and implements its operations in 
terms of Client_Server_With_Synchronous_Send's operations:

with Client_Server_With_Synchronous_Send;
package body Client_Server is
    -- Define stub subprograms for instantiation here.

    package Synchronous is new Client_Server_With_Synchronous_Send
       (Header_Type => Header_Type,
        Get_Length  => Get_Length,
        Set_Length  => Set_Length, ...);

    procedure Op (Header : in out Header_Type) renames Synchronous.Op;

    ...
end Client_Server;

-- 
Jeffrey Carter
"Now go away or I shall taunt you a second time."
Monty Python and the Holy Grail
E-mail: jeffrey_r_carter-nr [commercial-at]
         raytheon [period | full stop] com

Re: generics in Ada 83

[REH]

Jeffrey Carter wrote:
> Then you're in good shape. 1st, define your complete generic for using
> the synchronous send feature:
>
> generic -- Client_Server_With_Synchronous_Send
>     type Header_Type is private;
>
>     -- many formal subprograms
> package Client_Server_With_Synchronous_Send is
>     procedure Op (Header : in out Header_Type);
>
>     ...
> end Client_Server_With_Synchronous_Send;
>
> then define your shorter generic:
>
> generic -- Client_Server
>     type Header_Type is private;
>
>     with function Get_Length(Header : in Header_Type) return Integer;
>
>     with procedure Set_Length(Header : in out Header_Type;
>                               Length : in Integer);
> package Client_Server is
>     -- presumably a smaller set of operations than
>     -- Client_Server_With_Synchronous_Send
>     procedure Op (Header : in out Header_Type);
>
>     ...
> end Client_Server;
>
> Now, the body of Client_Server instantiates
> Client_Server_With_Synchronous_Send and implements its operations in
> terms of Client_Server_With_Synchronous_Send's operations:
>
> with Client_Server_With_Synchronous_Send;
> package body Client_Server is
>     -- Define stub subprograms for instantiation here.
>
>     package Synchronous is new Client_Server_With_Synchronous_Send
>        (Header_Type => Header_Type,
>         Get_Length  => Get_Length,
>         Set_Length  => Set_Length, ...);
>
>     procedure Op (Header : in out Header_Type) renames Synchronous.Op;
> 
>     ...
> end Client_Server;
> 

Thank you; much appreciated.

REH

Re: generics in Ada 83

[Jean-Pierre Rosen]

Jeffrey Carter a �crit :
> Defaults are defined for subprograms by inserting "is Name" or "is <>" 
> before the semicolon (;):
> 
>    with procedure Y (Z : in X) is A;
> 
> or
> 
>    with procedure Y (Z : in X) is <>;
> 
> You can't use the former, since it requires a procedure A, visible at 
> the point of the generic, that matches Y. Since you don't know what X is 
> at the point of the generic, you can't have such a procedure.
> 
Let me add something which is maybe not obvious to the OP:
In Ada, the legality of a generic is checked on the generic, not on the 
instantiation. This is a main difference with templates.

The benefit is that if a generic compiles, and the instantiation 
provides parameters that match the contract (of the generic formals), 
then the instantion is *always* OK.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: generics in Ada 83

[REH]

Jean-Pierre Rosen wrote:
> Jeffrey Carter a écrit :
> > Defaults are defined for subprograms by inserting "is Name" or "is <>"
> > before the semicolon (;):
> >
> >    with procedure Y (Z : in X) is A;
> >
> > or
> >
> >    with procedure Y (Z : in X) is <>;
> >
> > You can't use the former, since it requires a procedure A, visible at
> > the point of the generic, that matches Y. Since you don't know what X is
> > at the point of the generic, you can't have such a procedure.
> >
> Let me add something which is maybe not obvious to the OP:
> In Ada, the legality of a generic is checked on the generic, not on the
> instantiation. This is a main difference with templates.
>
> The benefit is that if a generic compiles, and the instantiation
> provides parameters that match the contract (of the generic formals),
> then the instantion is *always* OK.
>
Yes, thank you, I do know that.  I'm just trying to find a way to
shield the application programmers from dealing with noise they don't
care about.  I won't debate templates vs. generics.  I see advantages
to both, though I wil admit I prefer templates.

REH

Re: generics in Ada 83

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> The benefit is that if a generic compiles, and the instantiation
> provides parameters that match the contract (of the generic formals),
> then the instantion is *always* OK.

How is that different from templates? If the template compiles,
and the instantiation provides parameters such that all usage
within the template is legal, then the instantiation is OK.
Otherwise the program doesn't compile. Ada has explicit contracts
and C++ does "contract by usage" but in either language, once the
program compiles it is correct.

Supplying contracts in C++ would be vastly more difficult than it
is in Ada, because C++ has a variety of automatic conversions and
because C++ templates can be specialized whereas Ada generics cannot
be.

Re: generics in Ada 83

[Jean-Pierre Rosen]

Hyman Rosen a �crit :
> Jean-Pierre Rosen wrote:
> 
>>The benefit is that if a generic compiles, and the instantiation
>>provides parameters that match the contract (of the generic formals),
>>then the instantion is *always* OK.
> 
> 
> How is that different from templates? If the template compiles,
> and the instantiation provides parameters such that all usage
> within the template is legal, then the instantiation is OK.
> Otherwise the program doesn't compile. Ada has explicit contracts
> and C++ does "contract by usage" but in either language, once the
> program compiles it is correct.
> 
In Ada, there is no need to check legality on the expansion of the 
generic. Correct me if I'm wrong, but my understanding of templates is 
that the legality is rechecked for each instantiation.

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: generics in Ada 83

[Hyman Rosen]

Jean-Pierre Rosen wrote:
> In Ada, there is no need to check legality on the expansion of the
> generic. Correct me if I'm wrong, but my understanding of templates is
> that the legality is rechecked for each instantiation.

Well, in Ada, instantiations check the parameters for validity
against whatever contract the generic specifies for them. In C++,
the contract is implied by the usage within the template, so yes,
the legality is rechecked that way. But remember that in C++
template instatntiation is done strictly at compile-time. As far
as the programmer is concerned, either an instantiation validly
meets the template's requirements for its parameters, or the code
fails to compile, and that is true for both languages (or at least
I think that's true for Ada).

Re: generics in Ada 83

[Robert A Duff]

"Hyman Rosen" <hyman.rosen@gmail.com> writes:

> Jean-Pierre Rosen wrote:
> > In Ada, there is no need to check legality on the expansion of the
> > generic. Correct me if I'm wrong, but my understanding of templates is
> > that the legality is rechecked for each instantiation.
> 
> Well, in Ada, instantiations check the parameters for validity
> against whatever contract the generic specifies for them. In C++,
> the contract is implied by the usage within the template, so yes,
> the legality is rechecked that way. But remember that in C++
> template instatntiation is done strictly at compile-time. As far
> as the programmer is concerned, either an instantiation validly
> meets the template's requirements for its parameters, or the code
> fails to compile, and that is true for both languages (or at least
> I think that's true for Ada).

That's right.

The Ada way makes it easier to understand what the contract _is_.
And this implies that if you want to change the generic/template,
it's easier to understand whether or not you might break any clients.
(If you're writing a widely-used library, you might not have access to
all existing clients, so you can't compile them to see if they break.)
It also implies that the error messages are easier to understand,
especially with multiple layers of templates.

On the other hand, the C++ way is more powerful.

- Bob

Re: generics in Ada 83

[REH]

Robert A Duff wrote:
> "Hyman Rosen" <hyman.rosen@gmail.com> writes:
>
> > Jean-Pierre Rosen wrote:
> > > In Ada, there is no need to check legality on the expansion of the
> > > generic. Correct me if I'm wrong, but my understanding of templates is
> > > that the legality is rechecked for each instantiation.
> >
> > Well, in Ada, instantiations check the parameters for validity
> > against whatever contract the generic specifies for them. In C++,
> > the contract is implied by the usage within the template, so yes,
> > the legality is rechecked that way. But remember that in C++
> > template instatntiation is done strictly at compile-time. As far
> > as the programmer is concerned, either an instantiation validly
> > meets the template's requirements for its parameters, or the code
> > fails to compile, and that is true for both languages (or at least
> > I think that's true for Ada).
>
> That's right.
>
> The Ada way makes it easier to understand what the contract _is_.
> And this implies that if you want to change the generic/template,
> it's easier to understand whether or not you might break any clients.
> (If you're writing a widely-used library, you might not have access to
> all existing clients, so you can't compile them to see if they break.)
> It also implies that the error messages are easier to understand,
> especially with multiple layers of templates.
>
> On the other hand, the C++ way is more powerful.
>
> - Bob

That has got to be the best argument I have ever seem for Ada generics.

Thank you,
REH

Re: generics in Ada 83

[Hyman Rosen]

REH wrote:
> That has got to be the best argument I have ever seem for Ada generics.

Do remember, as has been frequently discussed here, that C++ templates
let you do things like define dimensioned objects that require zero
runtime overhead in either time or space and implicitly instantiate
themselves only for the units actually needed. This is far beyond what
Ada generics can do. The whole area of template metaprogramming is
unavailable to Ada as well.

Re: generics in Ada 83

[REH]

Hyman Rosen wrote:
> REH wrote:
> > That has got to be the best argument I have ever seem for Ada generics.
>
> Do remember, as has been frequently discussed here, that C++ templates
> let you do things like define dimensioned objects that require zero
> runtime overhead in either time or space and implicitly instantiate
> themselves only for the units actually needed. This is far beyond what
> Ada generics can do. The whole area of template metaprogramming is
> unavailable to Ada as well.

Oh, I'm still a big fan of templates.  I do a lot of template
metaprogramming, myself.  It is a very powerful tool.

Re: generics in Ada 83

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccbr2vpsh2.fsf@shell01.TheWorld.com...
>
> The Ada way makes it easier to understand what the contract _is_.
>
> On the other hand, the C++ way is more powerful.
>
Kinda like the difference between safety-matches and
strike-anywhere matches.   When I was a kid in rural
Pennsylvania, we used to call strike-anywhere matches
"barn burners."  Hmmmmm.  There is an analogy in
there someplace.

Richard Riehle

Re: generics in Ada 83

[Jim Rogers]

 
<adaworks@sbcglobal.net> wrote in news:rGJXe.399$9E2.124
@newssvr11.news.prodigy.com:

>  
> 
> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccbr2vpsh2.fsf@shell01.TheWorld.com...
>>
>> The Ada way makes it easier to understand what the contract _is_.
>>
>> On the other hand, the C++ way is more powerful.
>>
> Kinda like the difference between safety-matches and
> strike-anywhere matches.   When I was a kid in rural
> Pennsylvania, we used to call strike-anywhere matches
> "barn burners."  Hmmmmm.  There is an analogy in
> there someplace.
> 

My grandfather lived through the 1908 earthquake that destroyed
much of San Francisco. He was living in Santa Rosa, California
at the time. Santa Rosa is North of San Francisco.

The Santa Rosa area is now at the Southern end of the Sonoma
wine region. In 1908 the area had more breweries than wineries.

Anyway...
My grandfather told of how his house caught fire because a
large case of strike-anywhere matches fell off the shelf
of a store up the road and exploded, causing the destruction
of several dozen buildings including my grandfather's
house.

Jim Rogers

Re: generics in Ada 83

[Robert A Duff]

<adaworks@sbcglobal.net> writes:

> "Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
> news:wccbr2vpsh2.fsf@shell01.TheWorld.com...
> >
> > The Ada way makes it easier to understand what the contract _is_.
> >
> > On the other hand, the C++ way is more powerful.
> >
> Kinda like the difference between safety-matches and
> strike-anywhere matches.

Well, maybe, but I didn't really mean it that way.
I wrote the above to be a sort-of neutral comparison
of the Ada and C++ way of doing generics/templates.
Each has advantages.

The language designer in me wants to get the best of both.
Somehow...

>...   When I was a kid in rural
> Pennsylvania, we used to call strike-anywhere matches
> "barn burners."  Hmmmmm.  There is an analogy in
> there someplace.

I don't think one can buy strike-anywhere matches around here these
days.

- Bob

Re: generics in Ada 83

[adaworks]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wcc3bnyni4a.fsf@shell01.TheWorld.com...
>
> The language designer in me wants to get the best of both.
>
We have to be careful, I think, in comparing languages by citing
interesting features.   Taken as a whole, I still see the design of
Ada as more appropriate than C++ where reliability and
dependability are important.   A language that is prone
to springing little surprises on the programmer is not well-suited
to safety-critical software, regardless of little nicities of specific
features.

My analogy to strike-anywhere matches was intended to make
this point.   BTW, we can still buy these matches in some parts
of the country and they are really handy when one is camping.
It's just not a good idea to keep them around the house or near
children.

Ada is a little closer to the ideal of safety-matches.

Richard Riehle