Re: derived types, constants and literals

Re: derived types, constants and literals

[Robert I. Eachus]

In article <leschkes.783016480@ferret> leschkes@ferret.cig.mot.com (Scott Leschke) writes:

  > In Ada 83' constants of a type were not derived along with the
  > operations on that type.  For example:

  > package Test1 is
  >   type X is range 0..100;
  >   Null_Val : constant X := 0;
  >    procedure DoIt(Val : in X := Null_Val);
  > end Test1;

  > with Test1;
  > package Test2 is
  >   type Y is new Test1.X;
  >   B : constant Y := Null_Val;  -- doesn't compile
  > -- B : constant Y := Y(Test1.Null_Val);  -- compiles
  > end Test2;

   Did you think to try:

      function Null_Val returns X?

   Now B: constant Y := Null_Val; works just fine in both Ada 83 and
Ada 9X.  In Ada a lot of things that you normally think of as
constants (character literals and enumeration literals for example)
are defined as functions to get the appropriate behavior.  Just accept
the fact that an Ada constant is not a C constant or a FORTRAN
constant, and an Ada function is different from a C function or a
FORTRAN function and you won't have a problem.  (Ada constants don't
even have to be statically sized, let alone have static values,
whereas some Ada functions are defined to be static.)
        

  > It always struck me as odd that in Ada83, constants of a type could
  > not be derived and overridden just like operations were.  Since theyb
  > aren't, one of two possibilities exists for procedure Test2.DoIt.

  > Either it is derived as:
  >   procedure DoIt(Val : Y := Y(Test1.Null_Val));...

     Got it the first time.  In some cases this conversion may be more
than just a view conversion.

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: derived types, constants and literals

[Tucker Taft]

In article <leschkes.783016480@ferret>,
Scott Leschke <leschkes@ferret.cig.mot.com> wrote:

>Has standard type derivation been modified at all in 9X.

About the only change related to "untagged" derived types
is that a derived type declaration can have a new discriminant_part,
so long as the new discriminants are all used to constrain
the discriminants of the parent subtype.  This allows
a private type with discriminants to be implemented using
a derived type.

>In particular, I was wondering if constants of a type were
>derived just like the operations on that type.  From messing
>briefly with GNAT I gather that they can't and I was kind of
>wondering if this was ever considered.

Not really.  Having non-overloadable declarations inherited
upon type derivation would create a nasty mess.  However, 
you can accomplish roughly the same thing by declaring 
parameterless functions to represent your constant values, 
and they will be inherited like all other primitive subprograms.   
You can use pragma Inline if necessary to minimize any 
associated overhead.

> ...
>It always struck me as odd that in Ada83, constants of a type could
>not be derived and overridden just like operations were.  Since they
>aren't, one of two possibilities exists for procedure Test2.DoIt.
>
>Either it is derived as:
>
>   procedure DoIt(Val : Y := Y(Test1.Null_Val));

This is essentially what happens.  See RM83-3.4(13) and RM9X-3.4(22);5.0.

>or an implicit local constant Null_Val is generated of the form:
>
>   Null_Val : constant Y := Y(Test1.Null_Val);
> ...

No, this definitely doesn't happen.  A default expression can
be arbitrarily complicated.  It would not be possible to make
implicit local declarations for each "interesting" default expression.

> ...
>This is just a curiosity on my part but I thought others may be interested
>in this so I posted it.  If I was dreadfully wrong in this assumption,
>feel free to let me know.

As mentioned above, inheriting non-overloadable declarations could
create numerous surprises for the user.  It is a useful feature
of Ada that the only implicit declarations are for overloadable
things, and don't cause hiding when made visible via "use" clauses,
etc.

>Scott Leschke
>Motorola Cellular Infrastucture Inc.

S. Tucker Taft   stt@inmet.com
Ada 9X Mapping/Revision Team
Intermetrics, Inc.
Cambridge, MA  02138