Version 1.3 of ais/ai-00149.txt

Unformatted version of ais/ai-00149.txt version 1.3
Other versions for file ais/ai-00149.txt

!standard 08.06 (12)          00-10-04 AI95-00149/04
!class confirmation 96-09-04
!status received 96-09-04
!priority Low
!difficulty Easy
!subject Miscellaneous Confirmations
!summary
This AI includes a random assortment of questions that seem to have been answered satisfactorily via e-mail. The intent is that the ARG will not consider this AI in the forseeable future.
!question
!response
!appendix

!section 8.6(12)
!subject Are formal parameter names used in overload resolution ?
!reference RM95-8.6(12)
!reference AARM95-8.6(26.a)
!from Erhard Ploedereder 6-6-96
!reference 96-5595.a Erhard Ploedereder  96-6-5>>
!discussion

Are formal parameter names used in overload resolution ?  Consider:
  procedure Put(Int : Integer);
  procedure Put(Real : Float);
  function F return Float;
  function F return Integer;
  Put(F);             -- clearly ambiguous
  Put(Real => F);     -- but is this ambiguous ?
  Put(Int  => F);     -- or this ?

RM-8.6(12) on usage names (which the formal parameter names are in these
calls) seems to say that the calls in question are unambiguous.
(At least one Ada95 compiler takes this attitude.)

On the other hand, AARM 8.6(26a) makes these calls ambiguous (as they were
in Ada 83) by referring to type conformance in profiles as the only profile
related information used in overload resolution.

Which shall it be ?

****************************************************************

!section 8.6(12)
!subject Are formal parameter names used in overload resolution ?
!reference RM95-8.6(12)
!reference AARM95-8.6(26.a)
!reference 96-5595.a Erhard Ploedereder  96-6-5
!from Bob Duff
!reference 96-5596.a Robert A Duff 96-6-6>>
!discussion

> Are formal parameter names used in overload resolution ?

Yes.  As in Ada 83.

>...  Consider:
>   procedure Put(Int : Integer);
>   procedure Put(Real : Float);
>   function F return Float;
>   function F return Integer;
>   Put(F);             -- clearly ambiguous

Yes.

>   Put(Real => F);     -- but is this ambiguous ?
>   Put(Int  => F);     -- or this ?

No, the above two are *not* ambiguous.

> RM-8.6(12) on usage names (which the formal parameter names are in these
> calls) seems to say that the calls in question are unambiguous.
> (At least one Ada95 compiler takes this attitude.)

Sounds right.  (I hope *all* Ada 83 and Ada 95 compilers take this
attitude!)

> On the other hand, AARM 8.6(26a) makes these calls ambiguous (as they were
> in Ada 83) by referring to type conformance in profiles as the only profile
> related information used in overload resolution.

8.6(26.a) is talking about cases where an "expected profile" is
specified.  Expected profiles have nothing to do with calls.  Expected
profiles are used, for example, in determining which procedure body
belongs to which procedure declaration, and in subp renaming decls.
But a call is not a profile, so this paragraph does not apply to calls.

These calls were not ambiguous in Ada 83.  RM83-8.7(13) says, "The rules
given in 6.6, for the resolution of overloaded subprogram calls" are
used in overload resolution.  And RM83-6.6(3) says a call is ambiguous
if "...the names of the formal parameters (if named associations are
used)... are not sufficient to determine exactly one...".

So there is no change from Ada 83 here.

> Which shall it be ?

For named-notation calls, the formal parameter names are used in
overload resolution.

- Bob

****************************************************************

!section 8.6(12)
!subject Are formal parameter names used in overload resolution ?
!reference RM95-8.6(12)
!reference AARM95-8.6(26.a)
!reference 96-5595.a Erhard Ploedereder  96-6-5
!reference 96-5596.a Robert A Duff 96-6-6
!from John Barnes
!reference 96-5597.a John Barnes 96-6-7>>
!discussion
>
> > Which shall it be ?
>
> For named-notation calls, the formal parameter names are used in
> overload resolution.
>
> - Bob
>

Well that's a relief. There are thousnds of copies of my book out there
going back 15 years showing how you can distinguish a cow from a
garment by her name.

--
John Barnes

****************************************************************

!section B.3(00)
!subject C interface example
!reference RM95-B.3(page 341)
!from Mikael Espersen 96-10-16
!keywords examples C interface
!reference 96-5729.a Mikael Espersen 96-10-16>>
!discussion

In the example of using the Interfaces.C package there is a note:
"since the C function's return value is of no interest, the ADA interface
is a procedure"
I think that the note should be removed and the proper call to the C
function should be included, since the given example, in its present form,
is trivial in my opinion, where the correct call (also in ADA terms) would
be much more illustrative. The example is very good because its a
well-known C function, and if it is modified it will also give the reader
an idea of how to call common C functions, (which is not trivial in ADA!)
who contains out parameters.
__________________________________________________
M. Espersen, CRI A/S
Tel.: +45 45994 9686 Fax: +45 4594 9645 Email: mfe@cri.dk

****************************************************************

!section 3.3.1(31)
!subject Variable declaration examples include a constant
!reference RM95-3.3.1(31)
!from Gavin Finnie 96-11-04
!reference 96-5742.a Gavin Finnie  96-11-4>>
!discussion

The examples given of variable declarations include one which is actually a
constant declaration:

Hello    : constant String := "Hi, world.";

Either the word constant should be deleted or this example moved into those of
constant decarations in 3.3.1(33).

Gavin Finnie
gavin@praxis.co.uk

****************************************************************

!section A.4.3(34)
!subject Minor Inconsistency in Ada.(Wide_)Strings.Fixed
!reference RM95-A.4.3(34,95)
!from Wes Groleau 1996-11-22
!reference 96-5769.a W. Wesley Groleau (Wes) 96-11-22>>
!discussion

Many of the routines in Ada.Strings.Fixed have a parameter of

   Justify : in Alignment := Left;

but one of them has the semantically identical

   Justify : in Alignment := Strings.Left;

I suggest that any LRM revision make this consistent, but that
implementations be "grandfathered" to allow it to be either way.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------


****************************************************************

!section A.4.3(34)
!subject Minor Inconsistency in Ada.(Wide_)Strings.Fixed
!reference RM95-A.4.3(34,95)
!from Pascal Leroy 1996-11-25
!reference 96-5769.a
!reference 96-5773.a Pascal Leroy 96-11-25>>
!discussion

> Many of the routines in Ada.Strings.Fixed have a parameter of
>
>    Justify : in Alignment := Left;
>
> but one of them has the semantically identical
>
>    Justify : in Alignment := Strings.Left;
>
> I suggest that any LRM revision make this consistent, but that
> implementations be "grandfathered" to allow it to be either way.

The full name in the default value is necessary, because the subprogram in
question (Trim) has a parameter named Left (just two lines above), so the
constant Left is hidden from direct visibility (and the parameter Left is
hidden from all visibility, but that's another story).

Also note by the way that an implementation is allowed to change the
specification of predefined units, as long as that change is not detectable.
 So the above parameter declaration could be written:

        Justify : Alignment := Standard.Ada.Strings.Left;

and the implementation would still be conformant.  In fact, nowhere is an
implementation required to provide a source version of the predefined units.
 (I can think of one Ada 83 implementation which didn't provide the sources of
the predefined units, but just provided a library where the predefined units
where already compiled and ready to be used.)

Pascal

_____________________________________________________________________
Pascal Leroy                                    +33.1.30.12.09.68
pleroy@rational.com                             +33.1.30.12.09.66 FAX


****************************************************************

!section 13.3(59)
!subject     Storage_Size, pragma and attribute.
!reference RM95  13.3(59) to 13.3(67)
!from      Wes Groleau, 7 Jan 1997
!reference 97-15700.a W. Wesley Groleau (Wes) 97-1-7>>
!discussion

when you give pragma storage_size (X), the implementation must reserve
X OR MORE units or raise Storage_Error.  The attribute must return X  OR MORE.

An implementation is also allowed to have storage associated with a task
object which is NOT counted in the attribute's measurement.

I have some difficulties with the RM in these paragraphs:

1. RM says that the units are "storage elements" but the Annotated RM,
   hints in 13.3(66.a) that it's "bytes"  Now the definition of "byte" has
   been debated at length within the last six months, but I don't think the
   ARM gives it a definition.

2. the attribute 'Storage_Size is not worth much when you allow it to
   a. be larger than requested
   b. be less than the actual
   c. not include all the storage that a task object actually withholds from
      other parts of the system.

To put it another way, the following BOGUS interpretation does not
violate the RM:

   If you give a task "pragma Storage_Size(X);" then the system will reserve
   Y units of storage such that X < Y < unknown.  And the value of
   'Storage_Size will be Z such that X < Z < unknown.  Y may be greater than,
   less than, or equal to Z.  The system may actually consume an amount of
   space greater than Y or Z.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Senior Software Engineer - AFATDS                         FAX: 219-429-5194
Hughes Defense Communications (MS 10-41)                 Home: 219-471-7206
1010 Production Road                          (Mac): wwgrol@most.fw.hac.com
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------


****************************************************************

!section 13.3(59)
!subject     Storage_Size, pragma and attribute.
!reference RM95  13.3(59) to 13.3(67)
!reference 97-15700.a W. Wesley Groleau (Wes) 97-1-7
!from Bob Duff
!reference 97-15702.a Robert A Duff 97-1-8>>
!discussion

> when you give pragma storage_size (X), the implementation must reserve
> X OR MORE units or raise Storage_Error.  The attribute must return X  OR MORE.
>
> An implementation is also allowed to have storage associated with a task
> object which is NOT counted in the attribute's measurement.
>
> I have some difficulties with the RM in these paragraphs:
>
> 1. RM says that the units are "storage elements" but the Annotated RM,
>    hints in 13.3(66.a) that it's "bytes"  Now the definition of "byte" has
>    been debated at length within the last six months, but I don't think the
>    ARM gives it a definition.

The AARM is using the term "bytes" informally to mean "storage element".
On most machines these days, the two terms refer to the same thing.
The AARM is allowed to be sloppy like that; the RM is not.

> 2. the attribute 'Storage_Size is not worth much when you allow it to
>    a. be larger than requested

We have to allow it to be larger than requested, because we want to
allow the RTS to allocate in chunks.  E.g., it is perfectly reasonable
for an RTS to allocate all task stacks in multiples of 4096 bytes, and
any wording that forbids that is unacceptable.

>    b. be less than the actual

We wanted to allow complete freedom in the management of TCB's.  Some
RTS's want to allocate TCB's in some special area, perhaps in operating
system memory, and it really doesn't make sense to lump this storage in
with the storage for the task stack.  Consider for example an
implementation of Ada on top of Windows 95, where each Ada task is
mapped to a Win 95 thread.  The Ada implementer has no control over how
much storage is used by a Win 95 thread.

>    c. not include all the storage that a task object actually withholds from
>       other parts of the system.

I'm not sure how this is different from (b).  But in any case, the
purpose of pragma Storage_Size is *not* to make sure the task doesn't
use up too much memory, although it can be used in that manner if you
know something about your implementation.  The purpose is to make sure
that the task has enough memory for its own work.

> To put it another way, the following BOGUS interpretation does not
> violate the RM:
>
>    If you give a task "pragma Storage_Size(X);" then the system will reserve
>    Y units of storage such that X < Y < unknown.  And the value of
>    'Storage_Size will be Z such that X < Z < unknown.  Y may be greater than,
>    less than, or equal to Z.  The system may actually consume an amount of
>    space greater than Y or Z.

Yes.  But suppose the RM said that *exactly* X storage elements are
reserved, and that 'Storage_Size returns *exactly* X.  Would that be any
better?  No, because the RM doesn't define how much storage is used by
any given operation, and the RM allows Storage_Error to be raised by
*anything*.  E.g., the following "BOGUS interpretation" does not violate
the RM: Every time a task does an integer assignment, it uses up an
additional, unrecoverable, 1 megabyte chunk of memory.

So, the answer to your question is: Yes, the definition of Storage_Size
is vague.  But it has to be that way.  And one has to assume that
implementers are not deliberately trying to damage their customers.
This last part is true of many cases where the RM allows implementation
freedoms, especially low-level concerns like storage management, where
the RM really can't nail things down precisely.

In order to use Storage_Size effectively, you need to know some things
about your implementation: how is storage organized (stack, heap,
special TCB memory, etc), how much memory is used for various things,
how much the Storage_Size is rounded up, etc.

- Bob


****************************************************************

!section C.5(00)
!subject Discard_Names for enumeration types
!reference RM95-C.5
!from Keith Thompson 97-01-19
!reference 97-15706.a Keith Thompson 97-1-19>>
!discussion

If pragma Discard_Names is applied to an enumeration type, the semantics
of the Wide_Image and Wide_Value attributes are implementation defined.
The Image, Value, and Wide_Width, and Width attributes are still defined
in terms of Wide_Image and Wide_Value.

How much latitude do implementations have in this area?  May Enum'Image,
for example, raise an exception?  If it does, the definition of Enum'Width
becomes ambiguous; does it also raise an exception?

May Enum'Image be rejected at compile time, i.e., does illegality fall
within the meaning of "semantics"?

I presume it's legal to Enum'Image to fail (in some manner) for non-static
arguments but to succeed for static arguments, or more generally, for
arguments that can be evaluated at compilation time.  I also presume that
the identity Enum'Value(Enum'Image(E)) = E is not required to hold, even
if no exception is raised.

--
Keith Thompson (The_Other_Keith) kst@aonix.com <http://www.aonix.com> <*>
TeleSo^H^H^H^H^H^H Alsy^H^H^H^H Thomson Softw^H^H^H^H^H^H^H^H^H^H^H^H^H Aonix
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
"SPOON!" -- The Tick


****************************************************************

!section C.5(00)
!subject Discard_Names for enumeration types
!reference RM95-C.5
!reference 97-15706.a Keith Thompson 97-1-19
!from Bob Duff
!reference 97-15707.a Robert A Duff 97-1-21>>
!discussion

IMHO, the implementation has complete freedom to do whatever it likes in
this area.  Of course, I also think the Discard_Names feature shouldn't
even be in the language, so that may color my opinion.

> If pragma Discard_Names is applied to an enumeration type, the semantics
> of the Wide_Image and Wide_Value attributes are implementation defined.
> The Image, Value, and Wide_Width, and Width attributes are still defined
> in terms of Wide_Image and Wide_Value.
>
> How much latitude do implementations have in this area?  May Enum'Image,
> for example, raise an exception?  If it does, the definition of Enum'Width
> becomes ambiguous; does it also raise an exception?
>
> May Enum'Image be rejected at compile time, i.e., does illegality fall
> within the meaning of "semantics"?
>
> I presume it's legal to Enum'Image to fail (in some manner) for non-static
> arguments but to succeed for static arguments, or more generally, for
> arguments that can be evaluated at compilation time.  I also presume that
> the identity Enum'Value(Enum'Image(E)) = E is not required to hold, even
> if no exception is raised.

- Bob


****************************************************************

!section A.10.8(08)
!subject Reading an integer literal with a negative exponent
!reference RM95 A.10.8(8)
!reference RM95 2.4.1(5)
!from Pascal Leroy 97-03-10
!reference 97-15727.c Pascal Leroy 97-3-10>>
!discussion

A.10.8(8) says that the procedures Get read "the longest possible sequence of
characters matching the syntax of a numeric literal without a point."

The syntax of numeric literals is defined in RM95 2.4.1(2-5).  In particular,
RM95 2.4.1(5) states that "An exponent for an integer literal shall not have a
minus sign."  This is a syntax rule, not a static semantics rule.

Consider the case where the input file contains the sequence of characters
"10E-2X".  The syntax of a numeric literal is violated when the input scanner
encounters the character '-'.  Therefore, it seems that Data_Error must be
raised immediately after peeking that character.  An attempt to read an
additional character after Data_Error has been raised should then return the
character '-'.

This reasoning, which seems to follow naturally from the RM95 wording,
contradicts the ruling of AI83-00051, which required the input scanner to read
the characters "10E-2" and then raise Data_Error due to the fact that this
sequence is not a "legal" integer literal.  The next character to read after
Data_Error has been raised was, in Ada 83, the 'X'.

This issue shows up in ACVC test ce3704f.


****************************************************************

!section A.10.8(08)
!subject Reading an integer literal with a negative exponent
!reference RM95 A.10.8(8)
!reference RM95 2.4.1(5)
!from Dan Lehman 97-03-11
!reference 97-15727.c Pascal Leroy 97-03-10
!reference 97-15728.a Dan Lehman 97-3-11>>
!discussion

Pascal Leroy writes:

> A.10.8(8) says that the procedures Get read "the longest possible sequence
> of characters matching the syntax of a numeric literal without a point."
>
> The syntax of numeric literals is defined in RM95 2.4.1(2-5).  In particular,
> RM95 2.4.1(5) states that "An exponent for an integer literal shall not have
> a minus sign."  This is a syntax rule, not a static semantics rule.
>
> This reasoning, which seems to follow naturally from the RM95 wording,
> contradicts the ruling of AI83-00051, ...

I disagree:  the A.10.8(8) wording uses "numeric literal without a point",
NOT "integer literal" (and not "numeric_literal", either); in this, it's
consistent with Ada83.  I believe that AI83-00051 was never later challenged
with another Ada83 AI urging reconsideration (as a few early AIs were), and
hence the MRT saw no reason to change, and good reason not to change,
the I/O rules here?!

---Dan
------- *


****************************************************************

!section A.10.8(08)
!subject Reading an integer literal with a negative exponent
!reference RM95 A.10.8(8)
!reference RM95 2.4.1(5)
!from Robert Dewar 97-03-12
!reference 97-15727.c Pascal Leroy 97-03-10
!reference 97-15728.a Dan Lehman 97-3-11
!reference 1997-15729.a Robert Dewar 1997-3-12>>
!discussion

Pascal Leroy writes:

> A.10.8(8) says that the procedures Get read "the longest possible sequence
> of characters matching the syntax of a numeric literal without a point."
>
> The syntax of numeric literals is defined in RM95 2.4.1(2-5).  In particular,
> RM95 2.4.1(5) states that "An exponent for an integer literal shall not have
> a minus sign."  This is a syntax rule, not a static semantics rule.
>
> This reasoning, which seems to follow naturally from the RM95 wording,
> contradicts the ruling of AI83-00051, ...

Please note that in practice the ACVC establishes the semantics here not
the RM. It has always been this way, and all Ada 83 and Ada 95 compilers
agree with the ACVC and not with the RM, e.g.

     16#123456789abcdefg#

is expected to raise Data_Error if read as an integer, even though it is
clear that the longest possible sequence is just 16.

The discrepancy is a good thing. A literal reading of the RM here would
require lots of backup, causing implementation grief, and in practice would
be much less useful than the expected semantics!


****************************************************************

!section A.10.8(08)
!subject Reading an integer literal with a negative exponent
!reference RM95 A.10.8(8)
!reference RM95 2.4.1(5)
!reference Dan Lehman 97-03-11
!from Pascal Leroy 97-03-12
!reference 97-15730.a Pascal Leroy  97-3-12>>
!discussion

> I disagree:  the A.10.8(8) wording uses "numeric literal without a point",
> NOT "integer literal" (and not "numeric_literal", either); in this, it's
> consistent with Ada83.

I stand corrected.  I had failed to see the significance of "numeric literal
without a point" as opposed to "integer literal".  Although "an integer
literal is a numeric literal without a point" (RM95 2.4(1)), a numeric literal
without a point is _not_ an integer literal.  Silly me! :-)

To Bob Duff: this should go to the "stupid questions" AI.

Pascal

****************************************************************

!section 2.8(7)
!subject pragmas between 2 labels attached to the same statement.
!from  Alain Le Guennec
!keywords label pragma
!reference 97-15733.a Alain Le Guennec  97-3-21>>
!discussion

Please consider the following example:

   procedure Example is
   begin
      <<Label1>>
      pragma Annotate (Label1);
      <<Label2>>
      null;
   end Example;

The question is:
Is <<Label2>> legal here ?
According to 2.8(7), a pragma can be put where a syntactic category
ending by "statement" can (but not in place of such a construct).

The example above corresponds to:
  the_example_statement ::= label pragma label simple_statement

which I can't obtain starting with 5.1(3)
  statement ::= {label} simple_statement | {label} compound_statement
and then inserting "pragma" where it is allowed to do so.

The closest I can get with those rules is first:
  statement ::= label label simple_statement
then:
  statement ::= label label pragma simple_statement
but pragma can't seem to be inserted after the first label,
because of the second one.

I ask this because the GNAT compiler does not complain on this example,
and I'd like to know whether it should or not.

Regards,

--
Alain Le Guennec

****************************************************************

!section 2.8(7)
!subject pragmas between 2 labels attached to the same statement.
!keywords label pragma
!reference 97-15733.a Alain Le Guennec  97-3-21
!from Bob Duff
!reference 97-15738.a Robert A Duff 97-3-22>>
!discussion

> Please consider the following example:
>
>    procedure Example is
>    begin
>       <<Label1>>
>       pragma Annotate (Label1);
>       <<Label2>>
>       null;
>    end Example;
>
> The question is:
> Is <<Label2>> legal here ?

No.  I agree with your reasoning.

> According to 2.8(7), a pragma can be put where a syntactic category
> ending by "statement" can (but not in place of such a construct).
>
> The example above corresponds to:
>   the_example_statement ::= label pragma label simple_statement
>
> which I can't obtain starting with 5.1(3)
>   statement ::= {label} simple_statement | {label} compound_statement
> and then inserting "pragma" where it is allowed to do so.
>
> The closest I can get with those rules is first:
>   statement ::= label label simple_statement
> then:
>   statement ::= label label pragma simple_statement
> but pragma can't seem to be inserted after the first label,
> because of the second one.
>
> I ask this because the GNAT compiler does not complain on this example,
> and I'd like to know whether it should or not.

****************************************************************

!section 3.10(16)
!subject designated subtype of a subtype derived from an access type.
!reference RM95-3.10(16)
!reference RM95-4.8
!reference RM95-4.6
!from Dan Rittersdorf 97-05-12
!keywords designated subtype, access type, derived type
!reference 1997-15752.a Dan Rittersdorf 1997-5-12>>
!discussion

   An issue has been raised here at Concurrent regarding the designated
   subtype of a derived access type.

   For a particular example, consider test c34007f.ada in the 9xbasic
   portion of the ACVC 2.0.1 suite.  At line 130, constraint_error is
   expected.  It is not clear to me why, in light of sliding permitted by
   Ada95, unless I'm determining the designated subtype of T incorrectly.

   Consider these relevant declarations from the test:

           SUBTYPE COMPONENT IS INTEGER;

           TYPE DESIGNATED IS ARRAY (NATURAL RANGE <>) OF COMPONENT;

           PACKAGE PKG IS

                TYPE PARENT IS ACCESS DESIGNATED;

           END PKG;
           USE PKG;

           TYPE T IS NEW PARENT (IDENT_INT (5) .. IDENT_INT (7));

           X : T := ... ;

           ...

           X := NEW DESIGNATED'(6 .. 8 => 0);

   This assignment statement is expected to raise constraint_error, but
   if I determined the designated subtype correctly, it should not.

   The crux of the confusion seems to be the definition of the designated
   subtype involved.  Since T is a derived type, it isn't clear to me whether
   the designated subtype of T is

         DESIGNATED (IDENT_INT (5) .. IDENT_INT (7))

   applying the constraint of the derived access type T, or just

         DESIGNATED

   because the derived type's constraint is not applied to the designated
   subtype, but rather it keeps the parent type's designated subtype.

   If the constraint of T were to apply to the designated subtype of T,
   then the qualified expression above having bounds 6..8 would be
   implicitly converted to the designated subtype, having bounds 5..7,
   and all would be fine.

   Because the RM doesn't specifically say anything about the designated
   subtype of a derived type (derived from an access type), and the test
   expects behavior implying the unconstrained designated type, I must
   assume that the designated subtype of the derived type is the
   (unconstrained) designated subtype of the parent type, "DESIGNATED".
   Is this the case?

   It's a bit strange that the designated type would not be constrained by
   the constraint applied to the derived type declaration, since the
   constraint would apply if it were a normal access type definition.
   On the other hand, T is NOT defined by an access_to_object_definition,
   or an access_definition, so RM95 3.10(16) doesn't apply to T, does it?

   Your comments on the matter would be much appreciated.

   Thank you,

   Daniel G. Rittersdorf
   Lead Software Engineer
   Concurrent Computer Corporation

--
  Dan.Rittersdorf@mail.ccur.com        or              RittersdorfD@ACM.org
______________________________________________________________________________
  Concurrent Computer Corporation      |               Daniel G. Rittersdorf
  2101 W. Cypress Creek Rd.            |               178 Washington Street
  Ft. Lauderdale FL 33309              |               Sparta, MI 49345-1324
  Ph: +1 (954) 974-1700                |               Ph: +1 (616) 887-5431
______________________________________________________________________________

****************************************************************

!section 3.10(16)
!subject designated subtype of a subtype derived from an access type.
!reference RM95-3.10(16)
!reference RM95-4.8
!reference RM95-4.6
!reference 1997-15752.a Dan Rittersdorf 97-05-12
!from Tucker Taft 97-05-13
!keywords designated subtype, access type, derived type
!reference 1997-15753.a Tucker Taft 1997-5-13>>
!discussion

>    An issue has been raised here at Concurrent regarding the designated
>    subtype of a derived access type.
>
>    For a particular example, consider test c34007f.ada in the 9xbasic
>    portion of the ACVC 2.0.1 suite.  At line 130, constraint_error is
>    expected.  It is not clear to me why, in light of sliding permitted by
>    Ada95, unless I'm determining the designated subtype of T incorrectly.
>
>    Consider these relevant declarations from the test:
>
>
>            SUBTYPE COMPONENT IS INTEGER;
>
>            TYPE DESIGNATED IS ARRAY (NATURAL RANGE <>) OF COMPONENT;
>
>            PACKAGE PKG IS
>
>                 TYPE PARENT IS ACCESS DESIGNATED;
>
>            END PKG;
>            USE PKG;
>
>            TYPE T IS NEW PARENT (IDENT_INT (5) .. IDENT_INT (7));
>
>            X : T := ... ;
>
>            ...
>
>            X := NEW DESIGNATED'(6 .. 8 => 0);
>
>
>    This assignment statement is expected to raise constraint_error, but
>    if I determined the designated subtype correctly, it should not.
>
>    The crux of the confusion seems to be the definition of the designated
>    subtype involved.  Since T is a derived type, it isn't clear to me whether
>    the designated subtype of T is
>
>          DESIGNATED (IDENT_INT (5) .. IDENT_INT (7))
>
>    applying the constraint of the derived access type T, or just
>
>          DESIGNATED
>
>    because the derived type's constraint is not applied to the designated
>    subtype, but rather it keeps the parent type's designated subtype.

That is true.  The "designated subtype" never changes for an access *type*,
or any of its derivatives.  However, a constraint may be applied which
will apply to various *subtype*s of the access type or its derivatives.
If the constraint is specified as part of the derived type definition,
then it applies to all subtypes of that derived type.

The constraint of an access subtype is irrelevant during evalution of
the allocator, as that is only worried about the properties of the
underlying type, and its designated subtype (which in this case is
DESIGNATED, for PARENT any all of its derivatives).

However, the constraint of T becomes relevant on the assignment to X.
At that point, the designated object is checked to see whether it
satisfies the constraint of T.  No sliding applies to that check,
since the object already exists in the heap with particular array bounds.

>    If the constraint of T were to apply to the designated subtype of T,
>    then the qualified expression above having bounds 6..8 would be
>    implicitly converted to the designated subtype, having bounds 5..7,
>    and all would be fine.

I suppose, but that isn't the way it works.

>    Because the RM doesn't specifically say anything about the designated
>    subtype of a derived type (derived from an access type), and the test
>    expects behavior implying the unconstrained designated type, I must
>    assume that the designated subtype of the derived type is the
>    (unconstrained) designated subtype of the parent type, "DESIGNATED".
>    Is this the case?

Yes.  The designated subtype is a property of the type, and is inherited
as is by derived types.  An analogy would be the subtype of a component
of a record.  It is inherited as is by all derivatives.

>    It's a bit strange that the designated type would not be constrained by
>    the constraint applied to the derived type declaration, since the
>    constraint would apply if it were a normal access type definition.

A constraint that appears in an access type definition is very different
from one that appears in a subtype indication for an access subtype.
The constraint in an access type definition affects the objects in the
heap.  The constraint in a subtype indication for an access subtype
is a constraint on the pointers, restricting what they are allowed
to point at.  This is important because you are allowed to convert
back and forth between different derivatives of the same access type,
so they all must agree about the constraints that apply to the objects
in the heap.  By constrast, the constraint associated with particular
access subtypes can vary, even within a single access type, and checks
are required on assignment and conversion for those.

All in all, I think most observers agree that access subtypes are a waste
of energy, but they exist, and this ACVC properly tests the required
behavior.

>    On the other hand, T is NOT defined by an access_to_object_definition,
>    or an access_definition, so RM95 3.10(16) doesn't apply to T, does it?
>
>    Your comments on the matter would be much appreciated.

See above.

>    Thank you,
>
>    Daniel G. Rittersdorf
>    Lead Software Engineer
>    Concurrent Computer Corporation

-Tucker Taft  stt@inmet.com

****************************************************************

From: Christoph Grein
Sent: Thursday, May 11, 2000 12:00 AM

!topic Definition of Space
!reference RM95-A.4.1(4), RM95-A.3.3(8,21)
!from Christoph Grein 2000-05-11
!keywords haracter, space
!discussion

In package Ada.Strings, the object Space is defined as

  Space: constant Character := ' ';

While everybody should interprete this in the correct way, is it from a formal
point of view correctly defined?

See package Ada.Characters.Latin_1, where the same literal ' ' is used twice
for different objects, namely Space and No_Break_Space. Here it is made clear
in a comment which object is meant.

So is A.4.1(4) Space formally defined as Character'Val(32) or as
Character'Val(160)?

****************************************************************

From: Michael Yoder
Sent: Thursday, May 11, 2000 11:44 AM

The answer is at A.1(49), after the definition of Standard; this also
answers the question for hyphen and soft hyphen.

****************************************************************

From: srolsen@COLLINS.ROCKWELL.COM
Sent: Friday, September 22, 2000 8:17 PM

Description:

In procedure P, Q'Address could presumably refer to procedure Try_Ap.Q,
package Try_Ap_P1.Q, or the two Try_Ap_P2.Q procedures.

Here is the sample code:

   package Try_Ap_P1 is
   end Try_Ap_P1;

   package Try_Ap_P1.Q is
     procedure Q;
   end Try_Ap_P1.Q;

   package Try_Ap_P2 is
     procedure Q (A : Integer);
     procedure Q (A : Float);
   end Try_Ap_P2;

   with System;
   with Try_Ap_P1.Q;
   with Try_Ap_P2;

   package body Try_Ap is

     use Try_Ap_P1;
     use Try_Ap_P2;

     procedure Q is
     begin
       null;
     end Q;

     procedure P is
       A : System.Address;
     begin
       A := Q'Address;
     end P;

   end Try_Ap;

Desired response:

Which address will be assigned to A, the address of Try_Ap.Q, Try_Ap_P1.Q,
or one of the Q procedures in Try_Ap_P2?

What is the "rule" for selecting the procedure?

Is it correct to issue an error message or warning when this code is
compiled?  Please explain your answer.  Thank you.

****************************************************************

From: Tucker Taft
Sent: Friday, September 22, 2000 10:12 PM

> Which address will be assigned to A, the address of Try_Ap.Q, Try_Ap_P1.Q,
> or one of the Q procedures in Try_Ap_P2?

Try_Ap.Q.

> What is the "rule" for selecting the procedure?

The other Q's are not use-visible, because one is non-overloadable
and one is overloadable, so they "cancel out" as specified in 8.4(11).

> Is it correct to issue an error message or warning when this code is
> compiled?

It is not correct to issue an error message.  There are no rules about
issuing warnings -- compilers can pretty much do whatever they
want when it comes to warnings.

> Please explain your answer.  Thank you.

There is only one Q visible, so there is no ambiguity.  This is
because the multiple potentially use-visible Q's are not all overloadable,
so none of them are actually use-visible.

****************************************************************

From: Robert Dewar
Sent: Friday, September 22, 2000 10:09 PM

I agree with Tuck, this is a clear case.

****************************************************************

From: Robert A Duff
Sent: Saturday, September 23, 2000 2:28 PM

> There is only one Q visible, so there is no ambiguity.  This is
> because the multiple potentially use-visible Q's are not all overloadable,
> so none of them are actually use-visible.

Right, but one might wonder what Q'Address does when Q *is* overloaded
(eg if the package were removed from the example).
The answer is that the normal overload resolution rules apply: it's
ambiguous.  See 8.6.

****************************************************************

From: Erhard Ploedereder
Sent: Monday, September 25, 2000 3:10 AM

I agree. (And this is not worth an AI, since it is clear from the RM.)

****************************************************************

Questions? Ask the ACAA Technical Agent