CVS difference for acs/ac-00005.txt

Differences between 1.2 and version 1.3
Log of other versions for file acs/ac-00005.txt

--- acs/ac-00005.txt	2001/02/13 22:29:20	1.2
+++ acs/ac-00005.txt	2001/10/17 21:24:57	1.3
@@ -249,3 +249,199 @@
 to argue for :-)
 
 ****************************************************************
+
+From: V. Santhanam (Boeing)
+Sent: Tuesday, October  9, 2001 3:36 PM
+
+Issue:
+Ada 95 does not include any predefined modular types in package Standard.
+
+Proposed Solution:
+Add types Unsigned, Short_Unsigned, Long_Unsigned, etc. to parallel their
+signed integer type counterparts in Standard.
+
+Reasoning:
+Modular types, introduced in Ada 95, seem like second-class citizens in
+comparison to signed integer types. Ada should support these types just as
+whole-heartedly.
+
+****************************************************************
+
+From: David C. Hoos, Jr.
+Sent: Tuesday, October 9, 2001  8:25 PM
+
+What's wrong with the modular types in the package Interfaces?
+
+In what way are they not "supported as whole-heartedly?"
+
+****************************************************************
+
+From: Florian Weimer
+Sent: Wednesday, October 10, 2001  6:31 AM
+
+"Santhanam, Vdot" <vdot.santhanam@Boeing.com> writes:
+
+> Issue:
+> Ada 95 does not include any predefined modular types in package Standard.
+
+Yes.
+
+> Proposed Solution:
+> Add types Unsigned, Short_Unsigned, Long_Unsigned, etc. to parallel their
+> signed integer type counterparts in Standard.
+
+Use of such types tends to introduce portability problems.
+
+> Modular types, introduced in Ada 95, seem like second-class citizens in
+> comparison to signed integer types.
+
+I think there is a reason for this: Unlike signed integer types,
+arithmetic operations on modular types can silently yield results
+which depend on the modulus, which according to your proposal, is
+implementation-dependent.
+
+****************************************************************
+
+From: Marc Criley
+Sent: Wednesday, October 10, 2001  7:26 AM
+
+I submitted this request a few months ago, and the consensus was that such
+an addition is not warranted, due to the presence of predefined modular
+types in package Interfaces.
+
+I still disagree with that conclusion on the grounds that:
+
+- I wish to use such types as part of a self-contained Ada program that is
+not interfacing to anything, which use of package Interfaces tends to imply.
+
+- The modular types predefined in Interfaces are named in conjunction with
+the number of bits they occupy (Unsigned_16, Unsigned_32,etc.), yet the
+predefined integer type is not named in that manner.  I wanted a predefined
+modular type analogous to the predefined Standard.Integer type.
+
+However, I'm not going to get all worked up over it :-)  I can live with
+what's there.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 10, 2001  9:23 AM
+
+<<- The modular types predefined in Interfaces are named in conjunction with
+the number of bits they occupy (Unsigned_16, Unsigned_32,etc.), yet the
+predefined integer type is not named in that manner.  I wanted a predefined
+modular type analogous to the predefined Standard.Integer type.>>
+
+The reason we definitely do NOT want to add such a feature is that these
+non-portable types are a detriment to Ada in many people's view (and
+most coding standards forbid their use). I suspect that if backwards
+compatibility had not been an issue, we would have considered *removing*
+non-portable types from Standard :-)
+
+Indeed, look at 3.5.4(28) which expresses the viewpoint pretty clearly:
+
+28   An implementation should support Long_Integer in addition to Integer if
+the target machine supports 32-bit (or longer) arithmetic.  No other named
+integer subtypes are recommended for package Standard.  Instead, appropriate
+named integer subtypes should be provided in the library package Interfaces
+(see B.2).
+
+Of course this is only advice (and in fact GNAT does not follow that
+advice!)
+
+****************************************************************
+
+From: Pascal Obry
+Sent: Wednesday, October 10, 2001  9:48 AM
+
+
+Marc, Vdot,
+
+I do agree with you.
+
+Marc A. Criley writes:
+ > - I wish to use such types as part of a self-contained Ada program that is
+ > not interfacing to anything, which use of package Interfaces tends to imply.
+
+Good point.
+
+ > - The modular types predefined in Interfaces are named in conjunction with
+ > the number of bits they occupy (Unsigned_16, Unsigned_32,etc.), yet the
+ > predefined integer type is not named in that manner.  I wanted a predefined
+ > modular type analogous to the predefined Standard.Integer type.
+
+Indeed. I think that will make unsigned types a bit more visible.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, October 10, 2001  2:11 PM
+
+<<Proposed Solution:
+Add types Unsigned, Short_Unsigned, Long_Unsigned, etc. to parallel their
+signed integer type counterparts in Standard.>>
+
+Note that this would be a catastrophic non-upwards compatibility, since
+these are very very common type names, and suddenly programs using them
+would fail to compile, since now the wrong versions would be directly
+visible, overusing intended use visibility. Any name you add to standard
+has this problem, but to choose Unsigned as the name would be really
+perverse.
+
+****************************************************************
+
+From: Steven Deller
+Sent: Thursday, October 11, 2001  4:03 PM
+
+> > Proposed Solution:
+> > Add types Unsigned, Short_Unsigned, Long_Unsigned, etc. to parallel their
+> > signed integer type counterparts in Standard.
+>
+> Use of such types tends to introduce portability problems.
+
+So does use of integer, long_integer, etc.
+
+> > Modular types, introduced in Ada 95, seem like second-class
+> > citizens in comparison to signed integer types.
+>
+> I think there is a reason for this: Unlike signed integer types,
+> arithmetic operations on modular types can silently yield results
+> which depend on the modulus, which according to your proposal, is
+> implementation-dependent.
+
+That damnable silence :-).
+
+Of course using Ada.Interfaces *unsigned* types is a lie.  They aren't
+unsigned.  They are modular.  Unsigned types ought to have limits, which if
+exceeded, raise constraint error.
+
+So maybe we want *safe* (in the Ada way of raising an exception if limits
+are exceeded) unsigned types for Ada 0x.
+
+In addition to modular types (which, in my experience, are rarely the
+abstraction wanted in a program).
+
+But if not, then we are limited to Ada's broken unsigned abstraction, and
+putting unsigned_integer in STANDARD is arguably a reasonable way to give
+"unsigned types" parity with signed types.
+
+Keeping them "second class" citizens does nothing to make them safer.
+
+Just as we tell people to use
+   type my_int is range lo..hi ; -- for portability
+   x : my_int ;
+
+we would tell them to use
+   type my_mod is modulo 2**32 ; -- for portability
+   y: my_mod ;
+
+but they would be free to use
+   x : integer ;
+   y : unsigned_integer ;
+for non-portable situations.
+
+Actually, this seems to be a strong argument to REMOVE "integer", etc. from
+the Ada 0x STANDARD :-).  Why encourage sloppy programming by having that
+"attractive nuisance" that can cause injury.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent