Re: Types vs subtypes

Re: Types vs subtypes

[Richard Riehle]

Alex Angas wrote:

> I've been given an Ada project to work on and I'm trying to work out what
> the difference between using a type or subtype is. Why is myarray an array
> of st, instead of just making it an array of t in the following declaration?
>
>  type enum is ( red, green, blue ) ;
>  type t is array( enum ) of natural ;
>  subtype st is t;
>  type myarray is array( enum ) of st;
>

This is something that comes up a lot in my Ada classes.   I try to explain it
this way:

A type has
                      1)  a name
                      2)  a set of operations
                      3)  a set of values
                      4)  a wall between objects of itself and objects of other
types with differing type names

The last item, " a wall" is important in distinguishing structural equivalence
from name equivalence in the
Ada type system.

A subtype has

                     1)  a name
                     2)  a parent type
                     3)  the set of operations of its parent type
                     4)  either the same set of values of its parent type or a
constrained set of values
                     5)  no wall between operations between itself and its
parent type
                     6)  no wall between itself and other subtypes derived from
its parent or from itself

A subtype is structurally equivalent to its parent type and its subtype
siblings, but may have a smaller
range of legal values.

This should not be confused with a derived type where the first four items for a
subtype will hold, but not
the last two (5 and 6).

         type T1 is (Red, Orange, Yellow, Green, Blue, Indigo, Violet);
         type T2 is (Red, Orange, Yellow, Green, Blue, Indigo, Violet);

These are both separate types.  The properties for a type hold.

        X : T1;
        Y : T2;
          ...
        X := Y;         -- illegal
        Y := X;         -- illegal
        X : T1(Y);    -- illegal; this type conversion not permitted in this
case

Now,

        type T3 is new T1;  -- could have constrained the range
        Z : T3;

         ...

        X := Z;          -- illegal;  no structural equivalence permitted for
types
        X := T1(Z);   -- legal;  T3 is derived from T1 and X and Z are in same
derivation

Further,

       subtype T4 is T1 range Green..Violet;
       subtype T5 is T1;
       M : T4;
       P  :  T5;
         ...
       X  := M;   -- legal;  structurally equivalent
       M := X;    -- also legal but potential for constraint error at execution
time.
       P  := X;    -- legal;  no potential for constraint error since subtype
range is same as parent

Summary.

Use subtypes whenever you feel OK about relaxing the typing model.   Use types
when you want to
preserve strong typing.   Ada has several features that, when used with care,
allow the programmer
to relax the type model.   It is easier to start with a language design in which
the default is strong
type and relax that model than to start with a language where the default is
weak typing and make
it stronger.

This is not a complete exposition and not very rigorous computer science, but I
hope it helps.

Richard Riehle

Types vs subtypes

[Alex Angas]

I've been given an Ada project to work on and I'm trying to work out what
the difference between using a type or subtype is. Why is myarray an array
of st, instead of just making it an array of t in the following declaration?

 type enum is ( red, green, blue ) ;
 type t is array( enum ) of natural ;
 subtype st is t;
 type myarray is array( enum ) of st;

They both seem to compile the same. What am I missing?

Thanks for your help,
Alex.

Re: Types vs subtypes

[Marc A. Criley]

Richard Riehle wrote:

>A subtype is structurally equivalent to its parent type and its subtype
>siblings, but may have a smaller
>range of legal values.

Actually, there's a specific situation where this statement could be interpreted as
not necessarily being true--depending on how broadly one defines "structural
equivalence".  And which came as a surprise to us.

We had a situation where there was a

   type Counts is range 0..128;

that had a size clause:

   for Counts'Size use 32;

This then had a subtype

   subtype Indicies is Counts range 1..128;

Our expectation was that Counts'Size would be 32, and Indices'Size would be 32.
While that was in fact the case for the 'Size of Counts, Indices'Size turned out to
be 8.  We researched this in the RM (and could find no statement requiring that a
type's size be passed on to its subtypes), and also went back to our compiler
vendor, and confirmed that this behavior was correct.  It was, as Robert Dewar put
it, "in pure Ada 95...a nasty omission".  While size specification is retained
through derivation, it is not through subtyping.  And placing a Size specification
on a subtype is not permitted by the language.

We ended up utilizing the parent type in the external interface, relying on the use
of the subytpe throughout the remainder of the module to ensure the proper
constraints were obeyed.

Marc A. Criley
Software Architect
Lockheed Martin M&DS

Re: Types vs subtypes

[Jean-Pierre Rosen]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2186 bytes --]


"Marc A. Criley" <marc.a.criley@lmco.com> a �crit dans le message news: 39ABAAE7.3B4BEF29@lmco.com...
> We had a situation where there was a
>
>    type Counts is range 0..128;
>
> that had a size clause:
>
>    for Counts'Size use 32;
>
> This then had a subtype
>
>    subtype Indicies is Counts range 1..128;
>
> Our expectation was that Counts'Size would be 32, and Indices'Size would be 32.
> While that was in fact the case for the 'Size of Counts, Indices'Size turned out to
> be 8.  We researched this in the RM (and could find no statement requiring that a
> type's size be passed on to its subtypes), and also went back to our compiler
> vendor, and confirmed that this behavior was correct.  It was, as Robert Dewar put
> it, "in pure Ada 95...a nasty omission".  While size specification is retained
> through derivation, it is not through subtyping.  And placing a Size specification
> on a subtype is not permitted by the language.
>
> We ended up utilizing the parent type in the external interface, relying on the use
> of the subytpe throughout the remainder of the module to ensure the proper
> constraints were obeyed.
It seems that you assumed that *variables* declared of subtype Indices would use Indices'Size bits - and this is a misunderstanding.
Try this:

with Text_Io; use Text_Io;
procedure Essai is
   type Counts is range 0..128;
   for Counts'Size use 32;
   subtype Indices is Counts range 1..128;
   V_Counts  : Counts;
   V_Indices : Indices;
begin
   Put_Line ("Sizes:");
   Put_Line ("Counts:" & Integer'Image (Counts'Size));
   Put_Line ("Indices:" & Integer'Image (Indices'Size));
   Put_Line ("V_Counts:" & Integer'Image (V_Counts'Size));
   Put_Line ("V_Indices:" & Integer'Image (V_Indices'Size));
end Essai;

You'll see (with Gnat) that V_Indices has size 32.
In short: the 'Size for a (sub)type tells you the minimum number of bits required for it according to Shannon's theorem. If you want
to check the size used by a variable, declare a variable and take its 'size.

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

Re: Types vs subtypes

[Preben Randhol]

On Mon, 28 Aug 2000 16:20:11 -0700, Richard Riehle wrote:
>
>This is something that comes up a lot in my Ada classes.   I try to explain it
>this way:
>
>A type has
>                      1)  a name
>                      2)  a set of operations
>                      3)  a set of values
>                      4)  a wall between objects of itself and objects of other
>types with differing type names
>
>The last item, " a wall" is important in distinguishing structural equivalence
>from name equivalence in the
>Ada type system.
>
>A subtype has
>
>                     1)  a name
>                     2)  a parent type
>                     3)  the set of operations of its parent type
>                     4)  either the same set of values of its parent type or a
>constrained set of values
>                     5)  no wall between operations between itself and its
>parent type
>                     6)  no wall between itself and other subtypes derived from
>its parent or from itself
>
>A subtype is structurally equivalent to its parent type and its subtype
>siblings, but may have a smaller
>range of legal values.

Yes. I like to look at it in this (rough) way in accordance with the
syntax :

    type Height is new Integer;
    --          ^^^^^^
    -- Think of it as a new type.

    subtype Height is Integer;
    --             ^^
    -- Think of it as it _is_ Integer type and not a new one.

-- 
Preben Randhol - Ph.D student - http://www.pvv.org/~randhol/
"i too once thought that when proved wrong that i lost somehow"
                               - i was hoping, alanis morisette