Question about base types

Question about base types

[Matthew Heaney]

I have a question about the relationship between types, first named
subtypes, and base types.

If I declare an integer type, say

type T is range 1 .. 10;

Then I think that according to the Ada model this means I'm declaring some
unnamed type, but whose first named subtype is T:

type <anonomous parent of T> is System.Min_Int .. System.Max_Int;
subtype T is <anonomous parent of T> range 1 .. 10;

Do I have this correct?

Now what is the relationship of T'Base to this model?  Is T'Base the name
of the anonomous parent type

type T'Base is System.Min_Int .. System.Max_Int;
subtype T is T'Base range 1 ..  10;

Did the "anonmous parent" go away in Ada 95?  Or is it still

type <anon> is range System.Min_Int .. System.Max_Int;
subtype T is <anon> range 1 .. 10;

and T'Base simply "refers" to this anonomous type?

I can declare objects of type T'Base, right?

O : T'Base;

Is this declaration the same as

O : <anonomous parent of T>;

Enquiring minds want to know...

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Question about base types

[Robert A Duff]

In article <mheaney-ya023280002601971414080001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>
>I have a question about the relationship between types, first named
>subtypes, and base types.

Good question.  This terminology is pretty messed up in Ada.  Ada 95
cleans it up a little bit, but it's still pretty awful.  Sigh.

>If I declare an integer type, say
>
>type T is range 1 .. 10;
>
>Then I think that according to the Ada model this means I'm declaring some
>unnamed type, but whose first named subtype is T:

That's right (except it's called the "first subtype" in Ada 95).  ALL
types are unnamed.  You can never refer directly to a type in an Ada
program.  You can refer to the first subtype, or the base subtype, or
some other subtype.  These are all subtypes of the same underlying type.
We call that the "type of" the subtypes.

>type <anonomous parent of T> is System.Min_Int .. System.Max_Int;
>subtype T is <anonomous parent of T> range 1 .. 10;
>
>Do I have this correct?

Not exactly.  The above declaration declares a type.  Like all types, it
has no name.  It has a "base range", which is chosen by the
implementation.  The base range is NOT necessarily System.Min_Int
.. System.Max_Int.  The RM requires that the base range include all the
values in 1..10, and that it be symmetric about zero (or be symmetric
plus one extra negative value).  So the compiler could choose -10..10 as
the base range, or -11..10, or -1000..1000, or -1001..1000, etc.  The
expectation is that the compiler will choose something efficient, so
it's usually -2**15..2**15-1, or -2**31..2**31-1, or something like
that.  The base range determines when overflow happens -- that is, the
range used for intermediate results.  In particular, if the correct
answer is in the base range, then the result of the expression is that
correct answer.  Otherwise, the result is either the correct answer, or
you get an overflow (and Constraint_Error is raised).

(Note the difference between constraint checking and overflow checking
-- constraint checking is done on assignment, parameter passing, etc.
Overflow checking has to do with arithmetic operations.  Constraint
checking is often/usually done in software (using additional compare
instructions or whatever), whereas overflow checking is normally done by
the hardware (i.e. the add instruction automatically traps on overflow,
or at least automatically sets an overflow flag that can be checked in
one "trap on overflow" instruction).)

The "base subtype" of this type, called T'Base, is an unconstrained
subtype whose bounds are the base range.  The "first subtype" of this
type is called T, and it is constrained to 1..10.  Suppose the base
range happens to be -2**31..2**31-1 (which is allowed, since it includes
1..10, and is symmetric about zero, except for the extra -2**31 value).
Then:

    X: T := 10;
    Y: T'Base := 1_000_000_000;

If you assign the value 11 to X (as in X := X + 1;), there is a
constraint check, so Constraint_Error will be raised.  If you assign Y
:= Y*Y, there is no Constraint_Check.  However, they may be an overflow
check on the expression "Y*Y", so Y will either contain the value
1_000_000_000_000_000_000, or you will get Constraint_Error.  Most
likely the latter.

>Now what is the relationship of T'Base to this model?  Is T'Base the name
>of the anonomous parent type

No, T'Base is the name of an unconstrained subtype of the type.
Unconstrained means constraint checks are not done, but overflow checks
might be done.  In most compilers overflow checks *are* done, most of
the time, because otherwise the compiler would have to implement
arbitrary-sized integers in order to store the result.  The base subtype
T'Base still has a range associated with it -- namely, the base range
chosen by the compiler.  (And there are cases where it is more efficient
to get the right answer than to do the overflow check -- e.g. in
floating point, where the hardware might do a calculation in a
double-precision register.)

>type T'Base is System.Min_Int .. System.Max_Int;
>subtype T is T'Base range 1 ..  10;
>
>Did the "anonmous parent" go away in Ada 95?  

Yes.

>...Or is it still
>
>type <anon> is range System.Min_Int .. System.Max_Int;
>subtype T is <anon> range 1 .. 10;

No.  (And this isn't quite right for Ada 83, either.)

>and T'Base simply "refers" to this anonomous type?
>
>I can declare objects of type T'Base, right?
>
>O : T'Base;

Yes.

>Is this declaration the same as
>
>O : <anonomous parent of T>;

Well, not exactly, but you won't go too far wrong if you think of it
that way.  Just remember that the *compiler* chooses the base range, and
it is not usually Min_Int..Max_Int.

The anonymous type declared by "type T is range 1..10;" is considered to
be derived from root_integer, in the sense that this type belongs to the
class of all integer types.  However, this isn't the same sort of
derivation that happens when you write an explicit derived type decl --
in particular, the base range is not inherited from root_integer, but is
chosen by the compiler.  (This model is different from the Ada 83 model,
where the type of T is considered to be derived from some integer type
in Standard.  This doesn't make much difference in the behavior of
programs, but it does mean that compilers can support large ranges
without having any large-ranged types in Standard.)

To write strictly portable code, you have to make sure that every
expression result (of type T) is in the range -10..10.  If you want to
make sure all variables are in the range 1..10, but you want to allow
expression results in the range -1000..1000, then you should say:

    type Dummy is range -1000..1000;
    subtype T is Dummy range 1..10;

which guarantees that T'Base includes -1000..1000, and possibly more.
Then declare your variables to be of subtype T.

Note that the RM uses phrases like "the type Standard.Integer".
Strictly speaking, this is nonsense, since the name Standard.Integer
denotes a subtype, not a type.  The above wording is really a shorthand
for "the (unnamed) type that underlies the subtype Standard.Integer", or
"the (unnamed) type of the subtype Standard.Integer".

One final confusion: The term "anonymous type" does not mean "a type
that has no name", since *all* types have no name.  Instead, the term
"anonymous type" means "a type whose first subtype has no name".  For
example, "task T is ..." declares an object of an anonymous task type --
the first subtype of that type has no name.  (This explains why Ada 95
changed the term "first named subtype" to "first subtype" -- the first
subtype is not necessarily "named".)

For record types, and type extensions, 'Base is illegal.  This helps
ensure that there are no values of the type that don't belong to the
first subtype of the type.  For scalars, however, there can be values
outside the first subtype, and even values outside the base subtype.
(E.g., integer types represent the infinite range of mathematical
integers, most of which are outside the base range.  This infinite range
is generally used for compile-time calculations of static expressions,
but at run time, overflow checks normally prevent the actual use of the
infinite range.  Too bad -- see the recent language-war thread in which
several people have pointed out the advantages of having arbitrary
ranges at run time in Smalltalk.)

- Bob

Re: Question about base types

[Matthew Heaney]

In article <E4oE3q.1tq@world.std.com>, bobduff@world.std.com (Robert A
Duff) wrote:


>>type <anonomous parent of T> is System.Min_Int .. System.Max_Int;
>>subtype T is <anonomous parent of T> range 1 .. 10;
>>
>>Do I have this correct?
>
>Not exactly.  The above declaration declares a type.  Like all types, it
>has no name.  It has a "base range", which is chosen by the
>implementation.  The base range is NOT necessarily System.Min_Int
>.. System.Max_Int.  The RM requires that the base range include all the
>values in 1..10, and that it be symmetric about zero (or be symmetric
>plus one extra negative value).  So the compiler could choose -10..10 as
>the base range, or -11..10, or -1000..1000, or -1001..1000, etc.  The
>expectation is that the compiler will choose something efficient, so
>it's usually -2**15..2**15-1, or -2**31..2**31-1, or something like
>that.  The base range determines when overflow happens -- that is, the
>range used for intermediate results.  In particular, if the correct
>answer is in the base range, then the result of the expression is that
>correct answer.  Otherwise, the result is either the correct answer, or
>you get an overflow (and Constraint_Error is raised).

Can you point out to me where in the RM95 it states that the range of
T'Base must be symmetric around 0?

Can you point out to me where the RM95 states that the "portable range" of
T (our example here) need only be -10 .. 10?

This is sort of a bummer.  I had hoped that T'Base would give me something
nearer to System.Max_Int.  (But maybe you'll give me a reason why it won't
matter.)

Here's what I want to do.  Suppose I have a floating point heading type,
and I want to override its primitive add operator so that it behaves like a
modulo number, as you'd expect headings to do:

type Heading is digits 6 range 0.0 .. 360.0;

function "+" (L, R : Heading) return Heading;

function "-" (L, R : Heading) return Heading;

So that 

H : Heading := 359.0 + 2.0;   -- H has the value 1.0

H : Heading := 1.0 - 2.0;  -- H has the value 359.0

Can I do this implementation below, legally and portably?

function "+" (L, R : Heading) return Heading is
   Sum : constant Heading'Base := L + R;
begin
   if Sum > Heading'Last then
      return Sum - Heading'Last;
   else 
      return Sum;
   end if;
end;

Will the assignment to Sum ever cause Constraint_Error?

I could generalize this to be a generic:

generic
   type T is digits <>;
function Generic_Heading_Add (L, R : T) return T;

function Generic_Heading_Add (L, R : T) return T is
   Sum : constant T'Base := L + R;
begin
   if Sum > T'Last then
      return Sum - T'Last;
   else
      return Sum;
   end if;
end;

That way, I could use this any time I needed some sort of heading type

type Ownship_Heading is digits 4 range 0.0 .. 360.0;

function "+"  is new Generic_Heading_Add (Ownship_Heading);

So that I get this special "+" as the primitive op.

(I could generalize the algorithm even more, so I could use it for
Longitude types, too.)

The question is: what range of T'Base case I assume?  Am I guaranteed that
I won't get Constraint_Errors during the calculation of the  sum?  (Assume
the range of the actual type is 0 .. 360.)

Still confused...

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Question about base types

[Matthew Heaney]

In article <mheaney-ya023280003001970055250001@news.ni.net>, mheaney@ni.net
(Matthew Heaney) wrote:


>Here's what I want to do.  Suppose I have a floating point heading type,
>and I want to override its primitive add operator so that it behaves like a
>modulo number, as you'd expect headings to do:
>
>type Heading is digits 6 range 0.0 .. 360.0;
>
>function "+" (L, R : Heading) return Heading;
>
>function "-" (L, R : Heading) return Heading;
>
>So that 
>
>H : Heading := 359.0 + 2.0;   -- H has the value 1.0
>
>H : Heading := 1.0 - 2.0;  -- H has the value 359.0
>
>Can I do this implementation below, legally and portably?
>
>function "+" (L, R : Heading) return Heading is
>   Sum : constant Heading'Base := L + R;
>begin
>   if Sum > Heading'Last then
>      return Sum - Heading'Last;
>   else 
>      return Sum;
>   end if;
>end;

I think I've got it!

My type declarations should have been

type Heading_Base is digits 6 range 0.0 .. 720.0;
subtype Heading is Heading_Base range 0.0 .. 360.0;

function "+" (L, R : Heading) return Heading is
   Sum : Heading'Base := L + R;   -- Sum has the range 0.0 .. 720.0

Just a quick little question: the "+" operator is a primitive operation of
Heading_Base, right?  Can subtypes that are not first subtypes have
primitive operations (different from their parent's), or only first
subtypes?  (Or should I have said  ... only types?)

>generic
>   type T is digits <>;
>function Generic_Heading_Add (L, R : T) return T;
>
>function Generic_Heading_Add (L, R : T) return T is
>   Sum : constant T'Base := L + R;
>begin
>   if Sum > T'Last then
>      return Sum - T'Last;
>   else
>      return Sum;
>   end if;
>end;

So this will work if I instantiate it on type Heading, because then T'Base
will have the range I need.  So it's up to the instantiator to make sure
that T'Base has the required range.  And of course the spec of the generic
should have a comment or something about what the required range of T'Base
is.

You know, it would be really swell if the language had a way of formally
stating in the spec (rather than as comments) what the range of T'Base
needs to be.  Sound like another language you've heard of?  Une langue qui
parle francias?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Question about base types

[Robert Dewar]

Matthew asks

Can you point out to me where the RM95 states that the "portable range" of
T (our example here) need only be -10 .. 10?

  Obviously the base range need only cover the required range of the subtype
  being declared. Where can you possibly get any other idea from the RM?

This is sort of a bummer. I had hoped that T'Base would give me something
nearer to System.Max_Int.

  Of course not, it would be horribly inefficient on many machines to choose
  System.Max_Int as the base type of all integer types. Consider the case of
  GNAT where all implementations support at least 64-bits for Max_Int, but
  of course on many architectures, 64-bit arithmetic is not available, and
  has to be synthesized. You really do NOT want ordinary Integer arithmetic
  to have to use inefficient 64-bit arithmetic!

  If you want Max_Int, then use Max_Int!

  What T'Base gives you is an efficient hardware type big enough to hold
  your subtype.

Can I do this implementation below, legally and portably?

function "+" (L, R : Heading) return Heading is
   Sum : constant Heading'Base := L + R;
begin
   if Sum > Heading'Last then
      return Sum - Heading'Last;
   else
      return Sum;
   end if;
end;

  No you can't, because there is no guarantee that the range of Heading'Base
  exceeds the range of Heading. If you find this a "bummer" you have some
  fundamental misconceptions about the type system of Ada.

  What you need to do is to define a local subtype large enough to hold the
  sum and do conversions appropriately.

  A suggestion is to read up on how type declarations work in one of the
  good Ada text books (Norman Cohen's book is a good choice if you want
  something comprehensive). The RM is NOT a good source to learn basic
  stuff like this, you really need to know Ada pretty well before you
  can usefully use the RM as a reference source.

Re: Question about base types

[Matthew Heaney]

In article <dewar.854626377@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Can I do this implementation below, legally and portably?
>
>function "+" (L, R : Heading) return Heading is
>   Sum : constant Heading'Base := L + R;
>begin
>   if Sum > Heading'Last then
>      return Sum - Heading'Last;
>   else
>      return Sum;
>   end if;
>end;
>
>  No you can't, because there is no guarantee that the range of Heading'Base
>  exceeds the range of Heading. If you find this a "bummer" you have some
>  fundamental misconceptions about the type system of Ada.

Yes, Robert, that is probably the case.  Which is the reason for the post.

>  What you need to do is to define a local subtype large enough to hold the
>  sum and do conversions appropriately.

OK, I think I've got that part.

But here's another thing I'm confused about.  During the panel discussion
on Friday morning at TRI-Ada '95, Alexandar Stepanov said that he couldn't
do iteration in Ada 83.  What (I think) he wanted to do was to (actively,
not passively) iterate through an array, but to do that, your iteration
index has to fall off the end of the array (that's the termination
condition), the same way as it would it you were iterating through a linked
list (where the pointer would become null).

So I Alex was complaining that if you have (something like)

type AI is range 1 .. 10;
type AT is array (AI) of AC;

The index of an active iterator needs to have the range 1 .. 11, so Alex
said he didn't like Ada because he didn't have that range, and therefore
couldn't do (active) iteration.

So Tuck responded "That's what T'Base is for."

But it would seem that the only thing I can assume about T'Base is that it
has the same range as T, so what did Tuck mean?  How would it be used to
solve Alex' problem?

So what is T'Base for, exactly?  If, to guarantee a minimum range in which
to do intermediate calculations,  I must explicitly declare a (sub) type
with that range, and then subtype off of that to get the type I really care
about, what does T'Base buy me?  I can already do this in Ada 83, so why
was it added to the language, if I have to manually declare a supertype
anyway?  It seems I can't assume anything about its range (just that it
includes T), so why would I ever declare an object of the type T'Base?

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Question about base types

[Mats Weber]

> << << type Real is digits 7 range 0.0 .. 1.0;
> << << package Actual is new Example (Real =<< Real);
> << <<
> << << The implementation of Op needs to be able to do calculations independent
> << << of any range constraint on the actual parameter associated with the
> << << formal parameter Real. So it does its calculations using Real'Base:
> << <<
> << << function Op (Arg : Real) return Real is
> << <<    Result : Real'Base := Arg + 27.0;
> <<
> << This could fail (i.e. raise Constraint_Error), since 27.0 is not
> << required to be in the range of Real'Base. But it will work on most
> << machines because on reasonable implementations, floating point types are
> << mapped to representations that the hardware can handle efficiently (e.g.
> << IEEE). >>
> 
> This is a little misleading. While it is true that, unlike the case in
> Ada 83, where of course the base type of type Real must have a big range,
> the definitions of Ada 95 DO allow a narrow range IF that is what the
> hardware provides (I am assuming annex G is implemented). Since there are
> no machines with floating point types with 7 digits of precision and a
> range that does not include 27.0, nor could there ever be such machines,
> to worry about this eventuality is as silly as worrying about the fact
> that a legal Ada implementation could raise storage_Error for every
> possible program.

True. But if you know that you are going to need larger intermediate
results, then I think it is wiser to declare

   type Real_Base is digits 7;
   subtype Real is Real_Base range 0.0 .. 1.0;

than

   type Real is digits 7 range 0.0 .. 1.0;

Re: Question about base types

[Robert Dewar]

Mats said

<<True. But if you know that you are going to need larger intermediate  
results, then I think it is wiser to declare                          
                                                                      
   type Real_Base is digits 7;                                        
   subtype Real is Real_Base range 0.0 .. 1.0;                        
>>

Mats, you are confused, the base type (and hence the range of intermediate
results) is always unconstrained, so that if you write:

   subtype Real is digits 7 range 0.0 .. 1.0;

as in the original result, you will still get an unconstrained 7 digit
base type. 

Re: Question about base types

[Mats Weber]

> Mats, you are confused, the base type (and hence the range of intermediate
> results) is always unconstrained, so that if you write:
> 
>    subtype Real is digits 7 range 0.0 .. 1.0;

should type instead of subtype, right ?

> as in the original result, you will still get an unconstrained 7 digit
> base type.

So you are saying that

   type Real is digits 7 range 0.0 .. 1.0;   -- (1)

and 

   type Real_Base is digits 7;
   subtype Real is Real_Base range 0.0 .. 1.0;   -- (2)

are equivalent except for the existence of the name Real_Base ?

Well that's not what I get from reading RM 3.5.7(10). In the first case,
I get a safe (and base) range of at least -1.0 .. 1.0, and in the
second,
- 10.0 ** 28 .. 10.0 ** 28.

Now I know that this is not true for any reasonable implementation
because floating point base types are always created from a finite set
of representations available on the machine, but according to the RM
there could exist a legal implementation of Ada 95 for which 100.0 is a
possible value of Real'Base in variant (2) but not in variant (1). Or am
I missing soemthing ? (If I am, then the RM is confusing).

Re: Question about base types

[Robert Dewar]

Robert said

   <<type Real is digits 7 range 0.0 .. 1.0;

   as in the original result, you will still get an unconstrained 7 digit
   base type.>>

Mats said

<<Now I know that this is not true for any reasonable implementation
  because floating point base types are always created from a finite set
  of representations available on the machine, but according to the RM
  there could exist a legal implementation of Ada 95 for which 100.0 is a
  possible value of Real'Base in variant (2) but not in variant (1). Or am
  I missing soemthing ? (If I am, then the RM is confusing).>>

Robert says

I was definitely only talking about imaginable implementations. You cannot
imagine an implementation that has a 7 digit floating machine type which
excludes the value 100.0.

That's in the same realm as noting that the above declaration may raise
Storage_Error!

And I see nothing in the RM that would stop you choosing this base type
in both cases if your machine actually had it!

Re: Question about base types

[Robert Dewar]

Norman suggested:

<<So impressive, in fact, that I'm going to raise the bar:  Do you issue
the same warning for unintentionally recursive controlled-type
operations?  (For a controlled type CT, these would include a version of
Initialize that creates an uninitialized object of type CT, a version of
Adjust that assigns an object of type CT, or a version of Finalize in
which an object of type CT goes out of existence, either because it was
declared in finalize, because it was uncheckedly deallocated in
Finalize, or because it was created by an allocator for an access type
declared in Finalize.)

Such cases are especially hard to diagnose because the unintentional
recursive call is implicit, i.e., you won't find it in the program text.>>


Robert replies

At least some cases of this kind are caught:

     1.    with Ada.Finalization; use Ada.Finalization;
     2.    package a is
     3.       type m is new controlled with null record;
     4.       procedure Initialize (Object : in out m);
     5.    end a;

     1.    package body a is
     2.       procedure Initialize (Object : in out m) is
     3.          x : m;
                 |
        >>> warning: infinite recursion
        >>> warning: Storage_Error will be raised at runtime

     4.       begin
     5.          null;
     6.       end;
     7.    end a;

The diagnostic here is a little mysterious, but I would hesitate to
special case it unless someone really has run into this in practice.
Generally we like to apply the reality check of someone actually
(a) running into an error that could be caught and (b) being
mystified enough to waste time looking for the error. I always
hesitate to add new diagnostics that come only from thought
experiments.

Note that we are happy to get suggestions for error checks and improved
diagnostics. The best form for such suggestions is to send a complete
source program to report@gnat.com with a suggestion of exactly what
error message you would like to see. Now sometimes, such suggestions
amount to asking the compiler to read your mind, and it is impossible
to implement them, but it is remarkable how often we *have* been able
to sort things out, even in cases which at first look very hard.

Robert Dewar
Ada Core Technologies

Re: Question about base types

[Robert Dewar]

Bob Duff said

"Good question.  This terminology is pretty messed up in Ada.  Ada 95
cleans it up a little bit, but it's still pretty awful.  Sigh."

I actually do not agree that Ada 95 cleans it up. Yes, I know the
terminology in Ada 95 is more consistent, but it is also more at
odds with normal usage. The use of subtype for what everyone thinks
of as a type causes all sorts of confusion. For example, in Ada 95,
Integer is a subtype, and so is Integer'Base.

Yes, it is true that Ada 83 was a little confused in this area, but the
terminology chosen in Ada 95 is fundamentally confusing, and in fact I
note a couple of error messages in GNAT that are absolutely correct
but which always cause people trouble:

   package x is .... -- oops forgot this hid "type" x 

      q : x;
          |
     Error: subtype name expected

Almost all programmers react to this message thinking, "why do I need a
subtype here, a type should be good enough"

The fact that

  type x is ...

introduces the subtype x is bound to be confusing.

Sometimes we just decide to use the obvious terminology in GNAT instead
of the technically correct termiology, and we probably should do that
here too -- the message "type name expected
would be much clearer in this instance.

For example

    subtype x is integer range 1 .. 10;
    for x'size use 5;

GNAT says "rep clause cannot be given for subtype"


which is I think clear to people (at least no one ever asked for an
explanation of this message).

More accurate would be to say

  "rep clause may only be given for first named subtype"

but this seems more confusing to us.

As Bob said, a bit of a mess, and as I say, in my opinion, definitely NOT
improved in Ada 95 -- I preferred the Ada 83 terminology here (actually
there are a number of instances where Ada 95 has changed Ada 83
terminology that I think are ill-advised and cause confusion, but this
is the most noticable of them).

Re: Question about base types

[Matthew Heaney]

In article <dewar.855461358@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Yes, it is true that Ada 83 was a little confused in this area, but the
>terminology chosen in Ada 95 is fundamentally confusing, and in fact I
>note a couple of error messages in GNAT that are absolutely correct
>but which always cause people trouble:
>
>   package x is .... -- oops forgot this hid "type" x 
>
>      q : x;
>          |
>     Error: subtype name expected
>
>Almost all programmers react to this message thinking, "why do I need a
>subtype here, a type should be good enough"

Then we have to teach them that "types" don't have a name, only subtypes do.

>
>The fact that
>
>  type x is ...
>
>introduces the subtype x is bound to be confusing.

But we had first named subtypes even in Ada 83.  This declaration is
(simply) explained as "This declares a type whose first named subtype is
x."

>
>Sometimes we just decide to use the obvious terminology in GNAT instead
>of the technically correct termiology, and we probably should do that
>here too -- the message "type name expected
>would be much clearer in this instance.

Agreed.

>
>For example
>
>    subtype x is integer range 1 .. 10;
>    for x'size use 5;
>
>GNAT says "rep clause cannot be given for subtype"
>
>
>which is I think clear to people (at least no one ever asked for an
>explanation of this message).

I think it's ambiguous.  Do you mean a first named subtype, or non-first
named subtype?

>
>More accurate would be to say
>
>  "rep clause may only be given for first named subtype"
>
>but this seems more confusing to us.

Disagree.  That is the message I would *expect* to see.


>
>As Bob said, a bit of a mess, and as I say, in my opinion, definitely NOT
>improved in Ada 95 -- I preferred the Ada 83 terminology here (actually
>there are a number of instances where Ada 95 has changed Ada 83
>terminology that I think are ill-advised and cause confusion, but this
>is the most noticable of them).


I'm not disagreeing that this issue can be confusing; after all, I was the
one who submitted the original post!  When I was learning Ada 83, I
accepted that "first named subtypes" needed some special syntax to call
that fact out.  I think Ada 95 does improve things by always using the term
"subtype" instead of Ada 83's "type or subtype."

After all, we can always refer to the name of the subtype that appears in a
declaration that introduces a type as the "first named subtype," and refer
to other subtypes in that family as "non-first subtype."

But I'll admit it was only after a few years of using Ada 83 that I started
to understand all this business.

It is explained in some books, though, such as Barnes' Programming In Ada
and Bryan & Mendel's excellent Exploring Ada.  (You are even quoted in
there, Robert, about the price of houses in Palo Alto.)  Sadly, the latter
books (2 vols) are out of print.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Question about base types

[Robert Dewar]

Matthew Heany said (replying to me)

<<>which is I think clear to people (at least no one ever asked for an
>explanation of this message).

I think it's ambiguous.  Do you mean a first named subtype, or non-first
named subtype?

>
>More accurate would be to say
>
>  "rep clause may only be given for first named subtype"
>
>but this seems more confusing to us.

Disagree.  That is the message I would *expect* to see.>>

Robert replies:

Right, this is a quite typical reaction. In my experience, the biggest
enemy of good error messages from compilers is people who know too much,
and want the error messages to be technically correct at the level at
which they understand the language.

Matthew you don't *really* think this is ambiguous, in the sense that you
think it would confuse you surely -- since surely you know the language
well enough that you (a) know the rule involved anyway, and (b) you
understand the terminology issue to understand what GNAT means here.
Note that I am not just guessing that this message is clear, my metric
for concern about messages being unclear is a very simple one, I look
to see if anyone ever sends mail saying "what does this mean, I don't
understand".

Error messages should be designed to help people who do NOT know the rule
involved, and threfore, sort of by definition, are NOT experts in the
language. The phrase "first named subtype" is not likely to be in the
vocabulary of beginners, and you often simply confuse people by using
aggressively correct terminology.

Let me give some other examples:

I much prefer the message

  "generic package not allowed here"

Rather than 

  "package name required here"

Eveyrone knows a generic package is not a package, right? wrong!

Another example, I would always use the term package spec in an error
message, rather than package declaration, since in practice the latter,
term, though correct is not familiar.

Going back to types and subtypes, it seems obvious to any beginning
Ada programmer (and to a lot of not so beginning programmers) that

  type x is ....   introduces a type name

and

  subtype x is ...  introduces a subtype name

Yes, of course, we experts know that this is wrong, and can have fun 
scoffing at the uneducated hoi polloi who don't understand, but error
messages are meant to help people find their errors, NOT send people
somewhere else for help so that they can be educated on proper Ada
terminology.

Of course the best of both worlds would be to have the capability of
further explaining messages in extended text, where it might in some
cases be appropriate to explain the more precise terminology, and
even give an RM reference. As I have mentioned previously, this is a
tool that is on our list of useful things to do.

Meanwhile, my main useful input on error messages continues to be
mail from people who have genuinely found an error message that
confused them in a program they wrote themselves. The error messages
in GNAT have been constantly tuned against such input. I gave an
example in my previous message, a second semester Ada student (so
not someone who was a complete beginner) sent a message to me
with the fragment:

     1. procedure q is
     2.   x : q;
              |
        >>> subtype mark required in this context

     3. begin
     4.    null;
     5. end;

And could not understand the message. That's because the word subtype
set him thinking in the wrong direction. The real error was that he
had accidentally hidden his type name, but the word subtype got him
thinking "why should I need a subtype here, I don't see why a type
is not allowed?"

I also think the word "mark" is gratuitous here, and my inclination is
to change the message to read

  >>> type or subtype name required in this context

and in practice I think that would reduce the number of people who got
blocked by this message.

Remember, I never care about the expert who looks at a message, knows
what's wrong immediately, and thinks to themselves "that message is not
quite right". I worry only about avoiding people reading a message and
being puzzled and not being able to figure out how to fix their code
because the message is not sufficiently clear to them.

It's a definite philosophy which is certainly different from say the
inclination to give RM references on all messages. In GNAT we very
occasionally do give RM references if (a) there is a subtle rule that
cannot be summarized in one and (b) the rule in the RM is reasonably
clearly stated and accessible. For example:

     1. with System; use System;
     2. procedure q is
     3.   x : address;
     4.   y : String (1 .. 5) := "hello";
     5.   for y'Address use x;
                            |
        >>> invalid address clause for initialized object "y"
        >>> reference to variable "x" not allowed (RM 13.1(22))

     6. begin
     7.    null;
     8. end;

but that is definitely an exception.

Everyone can help improve error messages in GNAT (although I must admit
I will generally pay more attention to beginning students here than to
experts on CLA :-). If you really *do* find an error message that puzzles
you and you can't figure out the error, and think that an error message
change would help, send the comment along to report@gnat.com. On the
other hand, if your objection is a tecnical objection from an expert,
and you really knew what was wrong anyway, that's not such critical input.

Robert Dewar
Ada Core Technologies

Re: Question about base types

[Matthew Heaney]

In article <dewar.855492829@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:

>Of course the best of both worlds would be to have the capability of
>further explaining messages in extended text, where it might in some
>cases be appropriate to explain the more precise terminology, and
>even give an RM reference. As I have mentioned previously, this is a
>tool that is on our list of useful things to do.

I was wondering about that. I've only been a GNAT user for a week, and I
was a little surprised that the error messages didn't include an RM
reference automatically.  I figured there was some switch I could turn on
to get the RM references, too.

Compiling a program tests one's knowledge of the language.  From
time-to-time I'll do something I'm not sure is legal (more true now with my
new compiler), to see if it compiles.  When I get an error message, I like
to haul out the RM and look it up, to see the rule actually written on the
page. 

Admittedly, reading the RM is at times a painful process, but to really
understand the language, you have know how to navigate the RM.

So yeah, I think that adding the switch

-gnatmatt

to display messages for "expert" users would be a swell idea. ;)

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Question about base types

[Robert Dewar]

Matthew Heany said

<<I was wondering about that. I've only been a GNAT user for a week, and I
was a little surprised that the error messages didn't include an RM
reference automatically.  I figured there was some switch I could turn on
to get the RM references, too.

Compiling a program tests one's knowledge of the language.  From
time-to-time I'll do something I'm not sure is legal (more true now with my
new compiler), to see if it compiles.  When I get an error message, I like
to haul out the RM and look it up, to see the rule actually written on the
page.

Admittedly, reading the RM is at times a painful process, but to really
understand the language, you have know how to navigate the RM.

So yeah, I think that adding the switch

-gnatmatt

to display messages for "expert" users would be a swell idea. ;)
>>


Generally we find RM references pretty useless except to a rather small
group of people who can successfully read the RM. If you can't understand
the message in the first place, most people will not be enlightened by
an RM reference, except in certain unusual cases. It is interesting that
the suggestion to add RM references almost always comes from people who
are pretty much Ada experts, and this is NOT the class of people that
GNAT messages are aimed at!

And no, there is no thought at all of having a switch to display
different messages. The thought is a separate utility program.

Re: Question about base types

[Larry Kilgallen]

In article <mheaney-ya023680000902970112050001@news.ni.net>, mheaney@ni.net (Matthew Heaney) writes:
> In article <dewar.855461358@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> 
>>Yes, it is true that Ada 83 was a little confused in this area, but the
>>terminology chosen in Ada 95 is fundamentally confusing, and in fact I
>>note a couple of error messages in GNAT that are absolutely correct
>>but which always cause people trouble:
>>
>>   package x is .... -- oops forgot this hid "type" x 
>>
>>      q : x;
>>          |
>>     Error: subtype name expected
>>
>>Almost all programmers react to this message thinking, "why do I need a
>>subtype here, a type should be good enough"
> 
> Then we have to teach them that "types" don't have a name, only subtypes do.

And that is a shame, with regard popularization of Ada.

I am not claiming there is any better technical solution, but all who
encounter any situation where Ada is confusing to those experienced
in multiple other programming languages should realize that such a
situation is undesireable.

Larry Kilgallen

Re: Question about base types

[Robert I. Eachus]

In article <dewar.855492829@merv> dewar@merv.cs.nyu.edu (Robert Dewar) writes:

  > 5.   for y'Address use x;
  >                        |
  > >>> invalid address clause for initialized object "y"
  > >>> reference to variable "x" not allowed (RM 13.1(22))

   Boy, I don't like that one, but for a different reason.  I think
that any diagnostic for an implementation dependent rule should say
so.  i.e.  "reference to variable "x" not allowed by GNAT (see RM
13.1(22))" would be much more helpful, even to non-novice users.

     When porting code from one system to another these are the messages
that show up.  Somethimes the workaround is easy sometimes hard, but
it is a royal PAIN to spend time searching for why the blasted thing
doesn't work.  A diagonstic like this will have users looking at what
has been changed in the declaration of x, rather than starting to work
on the real problem.


--

					Robert I. Eachus

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

Re: Question about base types

[Robert Dewar]

Robert Eachus said

<<     When porting code from one system to another these are the messages
that show up.  Somethimes the workaround is easy sometimes hard, but
it is a royal PAIN to spend time searching for why the blasted thing
doesn't work.  A diagonstic like this will have users looking at what
has been changed in the declaration of x, rather than starting to work
on the real problem.>>

I'll say it again :-)

I never pay too much attention to what the Ada experts think *might* be
confusing. I pay attention to what real users actually *do* find confusing.
I find this a very useful distinction!

In this particular case, the RM reference is really very clear, and since
we changed this particular message, we (so far) have not had anyone be
mystefied by this particular message.

Robert Dewar
Ada Core Technologies

Re: Question about base types

[Mats Weber]

> I have a question about the relationship between types, first named
> subtypes, and base types.
> 
> If I declare an integer type, say
> 
> type T is range 1 .. 10;
> 
> Then I think that according to the Ada model this means I'm declaring some
> unnamed type, but whose first named subtype is T:
> 
> type <anonomous parent of T> is System.Min_Int .. System.Max_Int;
> subtype T is <anonomous parent of T> range 1 .. 10;
> 
> Do I have this correct?

No, but almost. the first line is wrong and should read

type <anonomous parent of T> is range <min> .. <max>;

where <min> and <max> are anonymous static implementation defined
constants that depend on the range you give in your type declaration.
For 1 .. 10, the compiler is quite likely to choose <min> = -128 and
<max> = 127 in order to store your type in a single byte.

> Now what is the relationship of T'Base to this model?  Is T'Base the name
> of the anonomous parent type

Yes

> type T'Base is System.Min_Int .. System.Max_Int;
> subtype T is T'Base range 1 ..  10;
> 
> Did the "anonmous parent" go away in Ada 95?  Or is it still

The mechanism has changed a little, but the effect remains basically the
same.

> I can declare objects of type T'Base, right?

You can in Ada 95, but not in Ada 83.

> O : T'Base;
> 
> Is this declaration the same as
> 
> O : <anonomous parent of T>;
> 
> Enquiring minds want to know...

This cannot be answered because the second declaration is illegal :-).

Re: Question about base types

[Robert A Duff]

In article <32ECD6B6.3B5A@elca-matrix.ch>,
Mats Weber  <Mats.Weber@elca-matrix.ch> wrote:
>For 1 .. 10, the compiler is quite likely to choose <min> = -128 and
><max> = 127 in order to store your type in a single byte.

The compiler can choose -2**31..2**31-1 for the base range, and still
store variables of subtype T in a single byte.  This makes sense if the
machine has a load instruction that takes a single byte from memory and
puts it in a 32-bit register.

- Bob

Re: Question about base types

[Robert Dewar]

Mats said

"No, but almost. the first line is wrong and should read

type <anonomous parent of T> is range <min> .. <max>;"


That's still wrong, or at least confusing, since it implies that the
anonymous parent of T is constrained, which is wrong.

The implicit declaration is more like

  type <anonymous parent of T> is new predefined-integer-type

where predefined-integer-type is one of the predefined base types, e.g.
integer'base (NOT integer).

Note that in Ada 95, the base types of integer types are NOT constrained,
for example Integer'Base is not a constrained type. Implementations are
allowed to restrict the values of type Integer'Base that they handle, but
conceptually, Integer'Base includes all possible integer values.

Re: Question about base types

[Robert I. Eachus]

In article <mheaney-ya023280002601971414080001@news.ni.net> mheaney@ni.net (Matthew Heaney) writes:

  > I have a question about the relationship between types, first named
  > subtypes, and base types.

  > If I declare an integer type, say

  > type T is range 1 .. 10;

  > Then I think that according to the Ada model this means I'm declaring some
  > unnamed type, but whose first named subtype is T:

  > type <anonomous parent of T> is System.Min_Int .. System.Max_Int;
  > subtype T is <anonomous parent of T> range 1 .. 10;

  > Do I have this correct?

  No.  The range of the anonomous type must be at least -15..15, but
the actual range is implementation dependent.

  > Now what is the relationship of T'Base to this model?  Is T'Base the name
  > of the anonomous parent type

  > type T'Base is System.Min_Int .. System.Max_Int;
  > subtype T is T'Base range 1 ..  10;

  There is no notation for declaring such an integer type in Ada.  The
type has a 'First and 'Last, but it has NO range constraint.

  > Did the "anonmous parent" go away in Ada 95?  Or is it still

  > type <anon> is range System.Min_Int .. System.Max_Int;
  > subtype T is <anon> range 1 .. 10;

  Arrggh!  One of the worst bugs in the Ada 83 RM, long since fixed.
So yes, it is gone in Ada 95.  (Well, not the anonymous type.  The
idea that there is a possible "equivalent" declaration in Ada.)

  > and T'Base simply "refers" to this anonomous type?

  Technically T'Base is a subtype of the anonomous type which contains
no constraint:

  subtype T'BASE is <anon>;

  > I can declare objects of type T'Base, right?

  > O : T'Base;

   Yes, but please don't name them O.

  > Is this declaration the same as

  > O : <anonomous parent of T>;

   Other than the fact that the second declaration is not legal in
Ada?  Not much difference.  Just remember that T'Base is a subtype of
the anonymous type which applies no constraint, and you are all set.

  > Enquiring minds want to know...

    Watch out, soon you may turn into a language lawyer.
--

					Robert I. Eachus

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

Re: Question about base types

[Mats Weber]

>   > If I declare an integer type, say
> 
>   > type T is range 1 .. 10;
> 
>   > Then I think that according to the Ada model this means I'm declaring some
>   > unnamed type, but whose first named subtype is T:
> 
>   > type <anonomous parent of T> is System.Min_Int .. System.Max_Int;
>   > subtype T is <anonomous parent of T> range 1 .. 10;
> 
>   > Do I have this correct?
> 
>   No.  The range of the anonomous type must be at least -15..15, but
> the actual range is implementation dependent.

I think this should be -10 .. 10. Nothing in the RM says it must be a
power of two minus one.

Re: Question about base types

[Robert I. Eachus]

   I said: 

   >   No.  The range of the anonomous type must be at least -15..15, but
   > the actual range is implementation dependent.

In article <32EE1434.3BB4@elca-matrix.ch> Mats Weber <Mats.Weber@elca-matrix.ch> writes:

   > I think this should be -10 .. 10. Nothing in the RM says it must be a
   > power of two minus one.

   Sigh, think of it as a ramification. ;-) You are correct that the
RM no longer requires that the range be based on a power of two, but
the rules for the attribute 'SIZE get mixed in here.  Since T'SIZE is
in (integer) bits, it must be 4 or greater (see 13.3).  Any range that
includes 1..10 is legal, including -5..10.  But T'BASE'SIZE must be at
least 5, because of the rule about symmetric ranges.  So there are at
least 31 possible values for an object of type T'BASE.  (Thirty-one?
Yep, thirty-one.  This is due to the dispensation for ones-complement
machines to allow for two zeros.)

   Since the anonymous type is unconstrained and contains all the
legal values of an object of type T'BASE, that means that there must
be at least 31 possible values, again distributed symmetrically around
zero, but there can be more.  And since the attribute is defined for
subtypes and objects, not types, it is possible for the size in bits
of an anonymous type to be log2(100) for example.  So minus one
hundred to ninety-nine would be a possible range, but minus ten to ten
would not be.

    Does this say that you can't put objects of (sub)type T in one
digit on a decimal machine?  No.  It says that objects of type T'BASE
sometimes require more space than objects of type T.  This has always
been a known ramification in Ada 83.  (In Ada 83 it only came up for
loop variables, in Ada 95 it can appear in lots of other places.)

--

					Robert I. Eachus

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

Re: Question about base types

[Robert A Duff]

In article <EACHUS.97Jan29150858@spectre.mitre.org>,
Robert I. Eachus <eachus@spectre.mitre.org> wrote:
>
>   I said: 
>
>   >   No.  The range of the anonomous type must be at least -15..15, but
>   > the actual range is implementation dependent.
>
>In article <32EE1434.3BB4@elca-matrix.ch> Mats Weber <Mats.Weber@elca-matrix.ch> writes:
>
>   > I think this should be -10 .. 10. Nothing in the RM says it must be a
>   > power of two minus one.

This is correct.  If you say "type T is range 1..10;", then T'Base will
be -10..10, or some range including that.  Period.  In both Ada 83 and
Ada 95.  For efficiency reasons, most compilers will choose a much
larger range, based on some power of 2, and 2's complement arithmetic.
But the only RM requirement here is that T'Base'Range be symmetric about
zero (plus perhaps one extra negative value), and include 1..10.

Sorry, but the stuff below is not correct.

>   Sigh, think of it as a ramification. ;-) You are correct that the
>RM no longer requires that the range be based on a power of two, but
>the rules for the attribute 'SIZE get mixed in here.  Since T'SIZE is
>in (integer) bits, it must be 4 or greater (see 13.3).  Any range that
>includes 1..10 is legal, including -5..10.  But T'BASE'SIZE must be at
>least 5, because of the rule about symmetric ranges.  So there are at
>least 31 possible values for an object of type T'BASE.  (Thirty-one?
>Yep, thirty-one.  This is due to the dispensation for ones-complement
>machines to allow for two zeros.)

"no longer"?  The rules are the same in Ada 83 and 95.  There is not,
and never was, any requirement for power-of-2 base ranges.

The rules for 'Size do *not* "get mixed in here".

Assuming the SP annex is supported, then T'Size=4, and T'Base'Size=5.
See 13.3(55).  But this has nothing whatsoever to do with the range of T
or T'Base.

Two zeros?  There is no dispensation -- there's only one zero for
integers in Ada.  If the machine is one's complement, and therefore has
two ways to represent zero, then the Ada compiler and/or hardware have
to make that fact invisible.

>   Since the anonymous type is unconstrained and contains all the
>legal values of an object of type T'BASE, that means that there must
>be at least 31 possible values,

No -- see above.

>... again distributed symmetrically around
>zero, but there can be more.  And since the attribute is defined for
>subtypes and objects, not types, it is possible for the size in bits
>of an anonymous type to be log2(100) for example.  So minus one
>hundred to ninety-nine would be a possible range, but minus ten to ten
>would not be.

No.  -10..10 is valid for T'Base'Range.

>    Does this say that you can't put objects of (sub)type T in one
>digit on a decimal machine?  No.  

A better answer is "Who cares?"

>...It says that objects of type T'BASE
>sometimes require more space than objects of type T.

True.

>...This has always
>been a known ramification in Ada 83.  (In Ada 83 it only came up for
>loop variables, in Ada 95 it can appear in lots of other places.)

True.

- Bob