Discriminant and type extensions

Discriminant and type extensions

[Hibou57 (Yannick Duchêne)]

Hello boys and girls,

I was looking at two of my generic packages, fully functionals, that
is not the trouble, but not expressive enough IMHO.

The lack, from my point of view, is in the way a type can be extended
from a another type with discriminants.

What I mean : I've got a type in a package, a tagged type with
discriminants. Then a second package extends this type, but the
discriminants from the extended type does not appears in the extension
declaration. When I want to instantiate the type (the extended one), I
obviously have to provide the actuals for these discriminants (the
ones coming from the type which was extended).

What do you think about it ?

Do you think it would be a good proposal to allow the discriminant to
be explicitly recalled in an extension declaration ? (just to be more
explicit and expressive)

Re: Discriminant and type extensions

[Robert A Duff]

"Hibou57 (Yannick Duch�ne)" <yannick_duchene@yahoo.fr> writes:

> I was looking at two of my generic packages, fully functionals, that
> is not the trouble, but not expressive enough IMHO.
>
> The lack, from my point of view, is in the way a type can be extended
> from a another type with discriminants.
>
> What I mean : I've got a type in a package, a tagged type with
> discriminants. Then a second package extends this type, but the
> discriminants from the extended type does not appears in the extension
> declaration. When I want to instantiate the type (the extended one), I
> obviously have to provide the actuals for these discriminants (the
> ones coming from the type which was extended).
>
> What do you think about it ?
>
> Do you think it would be a good proposal to allow the discriminant to
> be explicitly recalled in an extension declaration ? (just to be more
> explicit and expressive)

I'm not sure exactly what you mean, but you can do things like this:

    type T (D : Positive) is tagged ...
    type T2 (D : Positive; D2 : Boolean) is new T(D => D);
    type T3 is new T(D => 1_000_000);
    type T4 (D2 : Boolean) is new T(D => 1_000_000);

- Bob

Re: Discriminant and type extensions

[Adam Beneschan]

On Oct 5, 1:42 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> "Hibou57 (Yannick Duchêne)" <yannick_duch...@yahoo.fr> writes:
>
>
>
>
>
> > I was looking at two of my generic packages, fully functionals, that
> > is not the trouble, but not expressive enough IMHO.
>
> > The lack, from my point of view, is in the way a type can be extended
> > from a another type with discriminants.
>
> > What I mean : I've got a type in a package, a tagged type with
> > discriminants. Then a second package extends this type, but the
> > discriminants from the extended type does not appears in the extension
> > declaration. When I want to instantiate the type (the extended one), I
> > obviously have to provide the actuals for these discriminants (the
> > ones coming from the type which was extended).
>
> > What do you think about it ?
>
> > Do you think it would be a good proposal to allow the discriminant to
> > be explicitly recalled in an extension declaration ? (just to be more
> > explicit and expressive)
>
> I'm not sure exactly what you mean, but you can do things like this:
>
>     type T (D : Positive) is tagged ...
>     type T2 (D : Positive; D2 : Boolean) is new T(D => D);
>     type T3 is new T(D => 1_000_000);
>     type T4 (D2 : Boolean) is new T(D => 1_000_000);

Well, you can't do any of the last three, since you need an extension
part.  But we'll assume you meant to include one.  :)

I think he wants to try to duplicate the discriminants for
documentation purposes (for clarity), so that

      type T (D : Positive) is tagged ...

      type T2 (D : Positive) is new T with ...  -- [A]

where, I assume, the compiler would check to make sure the
discriminant part of T2 was something-conformant with that of T, and
the declaration would be semantically identical to

      type T2 is new T with ...

It (line [A]) isn't currently legal, but this is:

      type T2 (D : Positive) is new T (D=>D) with ...

However, I'd need to stare at the RM for some time to convince myself
that this is semantically identical in all cases to the simple "type
T2 is new T with...".  (And then I might have to open the RM and read
it after I'm done staring at it.)  Maybe it really is identical, and
all uses of T2 would have identical semantics in all cases.  I'm not
sure.

                             -- Adam

Re: Discriminant and type extensions

[Yannick Duchêne Hibou57]

Hi Bob,

On 5 oct, 22:42, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> I'm not sure exactly what you mean, but you can do things like this:

An example will tell more (I've dropped any kind of genericity here) :



package P1 is

   type T_Type (Discriminant : Natural) is
      tagged
      private;

private

   type T_Type (Discriminant : Natural) is
      tagged
      null record;

end P1;



with P1;

package P2 is

   type Extension_Type is
      new P1.T_Type
      with private;

   -- Extension_Type as a discriminant, but it
   -- does not explicitly appears in this
   -- package specification.

private

   type Extension_Type is
      new P1.T_Type
      with null record;

end P2;



with P2;

procedure Usage is

   Entity :
      P2.Extension_Type
         (Discriminant => 0);

   -- Indeed, it really has a discriminant,
   -- although the package interface does
   -- not express it.

begin
   null;
end;



I was thinking in this context, it may be nice to be able to express
again the discriminant at the place Extension_Type is declared. To be
honest, it happens too I feel it would be nice to something which
would allow to recall about the underlying interface which is left
implicit. Something similar to what the keyword “ overriding ” does.
The keyword “ overriding ” recalls about what is the underlying stuff,
making things more explicit. I was thinking about something similar.

For procedures and functions, the Renames clause may do the thing
(explicitly re-introducing procedures and functions in the scope), but
for discriminants in this kind of context, I do not know a way.
Perhaps I do not know it, or perhaps this may be a candidate proposal.

Re: Discriminant and type extensions

[Yannick Duchêne Hibou57]

Sorry, I was writing a reply to Bob in the time you wrote this one

On 6 oct, 00:04, Adam Beneschan <a...@irvine.com> wrote:
> I think he wants to try to duplicate the discriminants for
> documentation purposes (for clarity), so that
So I'm very happy to read this : yes, that's it ! You've understood me
very well.
This is for documentation purpose and clarity, *and* something the
compiler could check (so not comments).

I gonna try the “ type T2 (D : Positive) is new T (D=>D) with ... ” I
did not knew it is legal. If the compiler does not complain and check
it the expected way, it may be a good work-around.

Re: Discriminant and type extensions

[Yannick Duchêne Hibou57]

Re- Not legal, the compiler don't want this

Re: Discriminant and type extensions

[Adam Beneschan]

On Oct 5, 3:34 pm, Yannick Duchêne Hibou57 <yannick_duch...@yahoo.fr>
wrote:
> Re- Not legal, the compiler don't want this

Referring to the example where you removed the genericity:

If you put this on *both* the private and full declarations of
Extension_Type:

  type Extension_Type (Discriminant : Natural) is
     new P1.T_Type (Discriminant => Discriminant)

then take the (Discriminant => Discriminant) off the *private*
extension declaration.  I.e.:

  type Extension_Type (Discriminant : Natural) is
     new P1.T_Type
     with private;

But leave it on the full declaration:

  type Extension_Type (Discriminant : Natural) is
     new P1.T_Type (Discriminant => Discriminant)
     with null record;

See if that works.

The reason has to do with a rule about statically matching
constraints.  See AARM 7.3(13.e), at http://www.adaic.org/standards/05aarm/html/AA-7-3.html
-- look for paragraph 13.e.

                                    -- Adam

Re: Discriminant and type extensions

[Yannick Duchêne Hibou57]

On 6 oct, 01:08, Adam Beneschan <a...@irvine.com> wrote:
> then take the (Discriminant => Discriminant) off the *private*
> extension declaration.  I.e.:
>
>   type Extension_Type (Discriminant : Natural) is
>      new P1.T_Type
>      with private;
>
> But leave it on the full declaration:
>
>   type Extension_Type (Discriminant : Natural) is
>      new P1.T_Type (Discriminant => Discriminant)
>      with null record;
>
> See if that works.

Yes, it works

The message was indeed about statically matching constraint


Just beside, not directly related to this topic, but related to making
things explicit, I've found an nice way to recall about abstract
methods to be implemented by derived type.

If a base type is defined in a package and it is derived in a second
package, if it leaves some abstract methods undefined (still to be
given a concrete implementation), it can be show using both the
Overriding and Abstract clauses on the same declaration.

Here is an working example :


package P1 is

   type Base_Type is
      abstract
      tagged
      private;

   procedure Abstract_Method
     (Entity : Base_Type) is
      abstract;

private

   type Base_Type is
      abstract
      tagged
      null record;

end P1;

with P1;

package P2 is

   type Derived_Type is
      abstract
      new P1.Base_Type
      with private;

   overriding procedure Abstract_Method
     (Entity : Derived_Type) is
      abstract;
   -- Recalls about the inherited abstract method.
   -- Using both “ overriding ” and “ abstract ” is
   -- handled as expected : it does not create an
   -- homonymous method and really makes reference
   -- to the inherited one, thanks to the “ overriding ”,
   -- and clearly states it has no concrete implementation
   -- thanks to the “ abstract ”.

private

   type Derived_Type is
      abstract
      new P1.Base_Type
      with null record;

end P2;

Re: Discriminant and type extensions

[Jean-Pierre Rosen]

Hibou57 (Yannick Duch�ne) a �crit :
> Hello boys and girls,
> 
> I was looking at two of my generic packages, fully functionals, that
> is not the trouble, but not expressive enough IMHO.
> 
> The lack, from my point of view, is in the way a type can be extended
> from a another type with discriminants.
> 
> What I mean : I've got a type in a package, a tagged type with
> discriminants. Then a second package extends this type, but the
> discriminants from the extended type does not appears in the extension
> declaration. When I want to instantiate the type (the extended one), I
> obviously have to provide the actuals for these discriminants (the
> ones coming from the type which was extended).
> 
> What do you think about it ?
> 
> Do you think it would be a good proposal to allow the discriminant to
> be explicitly recalled in an extension declaration ? (just to be more
> explicit and expressive)
> 
See http://www.adalog.fr/qt11.htm (assuming you can read french ;-) )

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

Re: Discriminant and type extensions

[Yannick Duchêne Hibou57]

On 7 oct, 09:21, Jean-Pierre Rosen <ro...@adalog.fr> wrote:
> Seehttp://www.adalog.fr/qt11.htm(assuming you can read french ;-) )
Yes I do ;)
So I'm late : it was possible since Ada 95
Now I know

Re: Discriminant and type extensions

[Yannick Duchêne Hibou57]

On 6 oct, 00:15, Yannick Duchêne Hibou57 <yannick_duch...@yahoo.fr>
wrote:
> For procedures and functions, the Renames clause may do the thing
> (explicitly re-introducing procedures and functions in the scope), but
> for discriminants in this kind of context, I do not know a way.
> Perhaps I do not know it, or perhaps this may be a candidate proposal.

While this can be a bit dangerous too. Today I've faced an
unintelligible confusing bug. It was due to erroneously edited copy/
paste done while importing some entities in a current scope from the
scope of an instantiated packages.

If only there was a way to check that both parts of a rename clause
use the same name. Like checking that in “ NameX Declaration renames
PackageY.NameX ” both NameX are the same.

Is it a famous practice ? If it is enough, a syntax to check it, based
on existing reserve words would not be syntactic sugar, this would be
really useful check.

Why not reuse the For/Use pre-existing keywords ? To have something
like “ for NameX Declaration use PackageY.NameX ”. This may not
conflict with a representation clause. Or it may ?

Re: Discriminant and type extensions

[Jean-Pierre Rosen]

Yannick Duch�ne Hibou57 a �crit :

> If only there was a way to check that both parts of a rename clause
> use the same name. Like checking that in � NameX Declaration renames
> PackageY.NameX � both NameX are the same.
> 
Of course there is! Just use AdaControl:

check declaration (non_identical_renaming);

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