Version 1.1 of ais/ai-00367.txt

Unformatted version of ais/ai-00367.txt version 1.1
Other versions for file ais/ai-00367.txt

!standard 10.2.1          04-02-04 AI95-00367/00
!class amendment 03-12-07
!status work item 03-12-07
!status received 03-12-07
!priority Low
!difficulty Easy
!subject Include type declarations for Natural and Positive in Package Interfaces
!summary
!problem
!proposal
!wording
!discussion
!example
--!corrigendum
!ACATS test
!appendix

From: Currie Colket
Sent: Sunday, December 7, 2003  11:26 PM

!topic Include type declarations for Natural and Positive in Package Interfaces
!reference RM95-B.2
!from Klein 03-12-07
!keywords Integer, Positive, Natural, Package Interfaces
!discussion

Our use of Ada uncovered a series of type declarations that we would like
to see standardized in the language.  The Ada95 update to the language
provided specifically sized implementations of Integer and Unsigned (i.e.,
Interfaces.Integer_8, Interfaces.Unsigned_16).  However, the same was not
done for Positive or Natural subtypes of Integer.

We would like to propose that the standard incorporate the following
definitions into the predefined Interfaces package.

Positive_8,
Positive_16,
Positive_32
Natural_8,
Natural_16,
Natural_32

-x-x-x-x-x-x-x-x-x-x-x-snip-x-x-x-x-x-x-x-x-x-x-x-x-x-x
FYI, this request for an Ada language change was submitted to SIGAda by Judith
Klein via Dr. Alok Srivastava both working on FAA programs in Ada. Judith Klein
gave a keynote presentation on use of Ada in Air Traffic Control Systems at the
SIGAda 2000 Conference in Laurel, Maryland. She is the Chief SW Architect with
Lockheed Martin and has been given the recognition for successful development of
large ATC System in Ada. FAA is about to embark on a new major system
implementation using Ada.

We would appreciate it if you could consider this language change request for
the Ada 2005 amendment.
Thank you!

v/r
Currie Colket
Chair ACM SIGAda

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

From: Tucker Taft
Sent: Monday, December 8, 2003  6:16 AM

This proposal has no discussion or rationale.  On the surface
it doesn't seem like a good idea to me, but I am willing to
believe it has some important purpose.  Can you provide
at least a reference to some rationale?  Otherwise,
it is very hard to evaluate.

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

From: Craig Carey
Sent: Tuesday, December 16, 2003  1:20 AM

I just searched my collection of 7,951 *.ads files (excluding my own) and
found no code uses those 6 names except these two:

 * 5 GNAT files, 4 of which are similar. So after discarding 3 duplicates,
   there was 6 lines of use. However each use was inside of a comment.

 * The only other user of those types was an ObjectAda file. Here is some
   of it:

___________
package System.RTS.TGT.SYS_IO is

   -- **************************************************************************
   -- A simple package for very low level I/O to the host operating system.
   -- **************************************************************************

   subtype INTEGER_32 is Integer;
   subtype NATURAL_32 is INTEGER_32 range 0 .. INTEGER_32'LAST;
___________

Also the proposal would not cause a problem with my code.

File "/lib/rts/system.rts.tgt.sys_io.ads" does what I would do.
It defines Natural_32 and it does not use the Interfaces.Integer_32 type.

PS. an assert statement can be added to guarantee that an assumption is
held:

   use Ada.Assertions;  	--  AI95-00286. Have a use in each *.adb file
   pragma Assert (Interfaces.Integer_32'Base'Size = Integer'Size);

---

Can someone modify the proposal so that:
(1) the Natural_64, etc., types are added to some spec file, and
(2) subtypes are used appropriate. When the Integers are 32 +/- numbers,
then this would be the definition:

   subtype Integer_32 is Integer;
   subtype Natural_32 is Natural;
   subtype Positive_32 is Positive;

An exception could exist if Integers are 24 bit or whatever (I vaguely
recall that IBM's VM/SP had 24 bit addressing).

---

An aim is to have the code not malfunction when the number of bits in the
Integer type, changes (which could happen if the code is ported to
another compiler, e.g. it goes into an embedded machine).

Safety can result from avoiding Natural and using Natural_32 (or etc.)
 instead.

That might not happen because of the type mismatch error when a String
is indexed with Interfaces.Integer_32. The proposal seems to extend that
problem over to the Natural_32 type.

It seems fine to me, to weaken the type checking on existing code
by making Integer_32 be a subtype of Integer only if the Integer type
is implemented with an object with 32 bit precision.

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

From: Alok Srivastava
Sent: Monday, February 2, 2004  3:07 PM

FYI. Thanks Alok

-----Original Message-----
From: Klein, Judith [mailto:judith.klein@lmco.com]
Sent: Tuesday, December 16, 2003 12:55 PM
To: Srivastava, Alok (X-FAA); Schmidt, Richard B
Cc: Leeds, Daniel
Subject: RE: Ada 2005 is in the Works!

I'm sorry, I can't provide discussion or rationale. I'd ask why Ada95
updated the language to provide specifically sized implementations of
Integer and Unsigned (i.e., Interfaces.Integer_8, Interfaces.Unsigned_16).
We just found that it would have been helpful to also have Positive_8,
Positive_16, Positive_32, Natural_8, Natural_16, Natural_32, ... As well as
64 bit types.

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

From: Pascal Leroy
Sent: Tuesday, February 3, 2004  4:36 AM

I would like to offer a few comments on this:

1 - As explained in RM95 B.2(1), these types were introduced in Ada 95
because they are generally useful for interfacing with other languages
(including assembly) and/or with hardware.  Their main characteristic is
that they correspond to formats directly supported by the target
hardware (see RM95 B.2(8)).  In particular, they are the only types in
the language for which rotating and shifting subprograms are available.
From this perspective, Natural_n and Positive_n subtypes are not
particularly relevant, since the corresponding hardware operations and
formats generally don't have any equivalent to Ada subtypes.

2 - Therefore, while they can be used as such, these types are _not_
intended to replace user-defined types or subtypes for general usage.
At any rate, if in a particular situation there is a need for the
Natural_n and Positive_n subtypes, it's very easy for the user to
declare their own (possibly in a child of Interfaces, if appropriate).

3 - Note incidentally that there is some ambiguity as to what the
"proper" definition should be for Positive_n.  I could see it as a
subtype of Integer_n or as a subtype of Unsigned_n, and both definitions
might make sense depending on context.  Again, this argues for
application-specific declarations rather than predefined ones.

4 - I don't understand the issue about 64-bit types.  RM95 B.2(8) makes
it very clear that, on a 64-bit architecture, Integer_64 and Unsigned_64
should be supported.  It is equally clear that there is no such
requirement on a 32-bit architecture (or 16-bit, etc.).  In fact my own
reading of RM95 B.2 is that it actively _discourages_ an implementation
from providing 64-bit types on a 32-bit architecture, because the intent
of this section is to provide direct access to the target hardware,
without software simulation getting in the way of performance.  If your
compiler doesn't provide 64-bit types on 64-bit targets, you should talk
sternly to your vendor, but there is not much that the RM can do.

5 - There is a nasty compatibility issue with adding new declarations to
existing predefined units.  In the presence of use clauses, existing
code might become ambiguous if it happens to use the same identifiers.
Of course, there is a judgment call as to whether a given identifier is
likely to cause conflict or not.  In this instance, my gut feeling is
that there may well be projects out there that use the names Positive_n
and Natural_n, so I'd say that conflicts are quite likely.

Overall my assessment of this proposal is that (1) the implementation
cost is close to zero, at least as long as we don't require compilers to
simulate types that are not supported by the hardware; (2) the user
benefit is close to zero as these types were specifically intended for
interfacing, an area where subtypes are not terribly useful; (3) the
users who actually need these subtypes have probably defined them years
ago anyway; and (4) there is a substantial risk of introducing
incompatibilities.

Because of (4), I'd vote against the proposal.

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


Questions? Ask the ACAA Technical Agent