Version 1.3 of acs/ac-00005.txt

Unformatted version of acs/ac-00005.txt version 1.3
Other versions for file acs/ac-00005.txt

!standard 3.5.4 (11)          01-01-23 AC95-00005/01
!class uninteresting 01-01-23
!status received 01-01-19
!subject A general-purpose modular type ought to be predefined
!summary
!appendix

From: Marc Criley
Sent: Friday, January 19, 2001 11:01 AM

There are two kinds of integer_type_definitions, a
signed_integer_type_definition and a modular_type_definition [3.5.4(2)].
Yet a predefined type, Integer, exists for only one of these [3.5.4(11)].

It would seem reasonable to additionally predefine an analogous general
purpose modular subtype. The semantics of such a type are certain to be
reasonably well-grasped by programmers, as "unsigned" types have long been
employed in the software industry.

While it is good practice for developers to define appropriate types rather
than rely on predefined general-purpose ones, Ada did see fit to predefine
both Integer and Float.  If situations can be envisioned where it is
appropriate to employ those types, it is not hard to conceive of ones where
a predefined modular type would be equally useful.  Currently in such
situations, developers must define their own modular type (possibly
resulting in redundant definitions by different programmers) or employ an
Interfaces.C.Unsigned_... type (despite there perhaps being no reason to
otherwise utilize the C interface package).

I would propose the name "Cardinal" for such a subtype, as its nature is
equivalent to that of Modula-2's CARDINAL type.  (Though I would not be at
all surprised to learn that some other programming language's use of the
term CARDINAL predates M2, but M2 is where I first encountered it.)

The definition of Cardinal should be, in effect:

   type Cardinal is mod System.Max_Binary_Modulus;

A paragraph can then be added to 3.5.4, reading:

"There is a predefined modular subtype named Cardinal, declared in the
visible part of package Standard.  It is contrained to the base range of its
type."

I expect there may also be an Implementation Requirement in that section:

"In an implementation, the range of Cardinal shall include the range 0 ..
2**16."

Marc A. Criley
Senior Staff Engineer
Quadrus Corporation
(256) 971-6932

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

From: Randy Brukardt
Sent: Friday, January 19, 2001 1:21 PM

> type (possibly resulting in redundant definitions by different
> programmers) or employ an Interfaces.C.Unsigned_... type (despite
> there perhaps being no reason to otherwise utilize the C interface
> package).

You're mistaken: Unsigned_... is directly in package Interfaces; they have
no connection to a particular programming language. These types were defined
for the sort of use you envision, without the name-space pollution issues of
declaring something in Standard.

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

From: Pascal Leroy
Sent: Friday, January 19, 2001 3:04 PM

> A paragraph can then be added to 3.5.4, reading:
>
> "There is a predefined modular subtype named Cardinal, declared in the
> visible part of package Standard.  It is contrained to the base range of
> its type."

Ignoring the question of whether this type would be useful or not, I want to
insist on the name pollution problem mentioned by Randy: at this point
adding any name to Standard is a no-no, unless that name is so ridiculously
contrived that we can be pretty sure it was never used by anyone in the last
18 years.

Cardinal is a perfectly good name, e.g. to denote the number of elements in
a set, and adding it to Standard would probably cause silent visibility
changes in existing programs.  We definitely don't want that...

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

From: Marc Criley
Sent: Saturday, January 20, 2001 10:09 AM

I definitely agree that this would be a problem, so I retract the proposed
addition of this name to package Standard, as the identifier "Cardinal" must
certainly already be present in Ada software.

Continuing to address just this question, I've not been party to any
discussions about it, so my apologies if what I say here is redundant.

Other candidate packages for "new" standard identifiers:
   package Ada - While currently an empty package, it would
                 seem not out-of-line to place identifiers
                 in this package that would have been placed
                 in package Standard if it were done all
                 over again.
   (new packages)
   package Ada.Predefined, Ada.Predefinitions, or Ada.Canonical

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

From: dewar@gnat.com
Sent: Saturday, January 20, 2001 10:43 PM

Marc said:

Other candidate packages for "new" standard identifiers:
   package Ada - While currently an empty package, it would
                 seem not out-of-line to place identifiers
                 in this package that would have been placed
                 in package Standard if it were done all
                 over again.
   (new packages)
   package Ada.Predefined, Ada.Predefinitions, or Ada.Canonical


why not package Interfaces -- where these types are already defined!

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

From: Christoph Grein
Sent: Monday, January 22, 2001 1:16 AM

And I think the name Interfaces is exactly appropriate since these types
describe interfaces to the hardware, don't they.

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

From: Marc Criley
Sent: Monday, January 22, 2001 7:42 AM

Randy Brukardt wrote:

> You're mistaken: Unsigned_... is directly in package Interfaces; they have

Brain f*rt on my part, since my use of the Interfaces packages is always
along the C branch, one starts thinking that all this stuff is on that
branch.

> no connection to a particular programming language. These types were
> defined for the sort of use you envision,

But the use I envision has _nothing_ to do with interfacing to foreign
languages, in fact the motivation for this suggestion came out of work I'm
doing on a tool that is 100% Ada, that is intended to operate only on other
Ada software (via ASIS).

> without the name-space pollution issues
>   of declaring something in Standard.

I responded to Pascal's reiteration of the concern about name space
pollution, agreeing that it would almost always be ill-advised to add new
identifiers to package Standard, and retracting the suggestion that Cardinal
be placed in that package.  And thence went looking for another home for
such a type, suggesting the package Ada itself, or creating a new package
such as Ada.Predefined, Ada.Predefinintions, or Ada.Canonical.


In situations where a general purpose, full-range, modular type may be
justifiably employed (analogous to areas where the types Float, or Integer
and its subtypes are used), it seems unwarranted to drag in the Interfaces
package just to get such a type.  There are "pure Ada" contexts where such a
predefined cardinal type could be put to good use.

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

From: Randy Brukardt
Sent: Monday, January 22, 2001 6:35 PM

> Marc wrote:

> But the use I envision has _nothing_ to do with interfacing to foreign
> languages, in fact the motivation for this suggestion came out of work I'm
> doing on a tool that is 100% Ada, that is intended to operate
> only on other Ada software (via ASIS).

You're *still* thinking too narrowly about "Interfaces". This is about
interfacing to *anything*: another programming language, a piece of
hardware, a software file format, etc. Indeed, you can even think of it as
interfacing to a CPU register, that is, selecting a type with an efficient
representation on your processor.

In any case, use of predefined types (with the possible exception of String)
should be discouraged, so there doesn't seem to be much point in declaring
more of them.

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

From: dewar@gnat.com
Sent: Monday, January 22, 2001 11:46 PM

<<In situations where a general purpose, full-range, modular type may be
justifiably employed (analogous to areas where the types Float, or Integer
and its subtypes are used), it seems unwarranted to drag in the Interfaces
package just to get such a type.  There are "pure Ada" contexts where such a
predefined cardinal type could be put to good use.>>

But that's all there IS in interfaces, a few useful types ...

most of Interfaces is the unsigned types, then there are three float
types at the end for IEEE float types, but you talk of "dragging in"
EXACTLY what you are asking for, 90% of the Interaces package is devoted
to these standard unsigned types. If we move them elsewhere, then that
package would be just as long!

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

From: Marc Criley
Sent: Tuesday, January 23, 2001 8:36 AM

I concede to Randy's and Robert's arguments that the Interfaces package is
where the specific kind of type I'm talking about should reside.  I don't
totally agree, but...that's okay :-) :-)

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

From: dewar@gnat.com
Sent: Tuesday, January 23, 2001 1:52 PM

<<I concede to Randy's and Robert's arguments that the Interfaces package is
where the specific kind of type I'm talking about should reside.  I don't
totally agree, but...that's okay :-) :-)
>>

Well there is some basis for raising this issue 8 years ago, since indeed
it is a little confusing that the unsigned types are in a place primarily
concerned with interfaces to other languages etc.

But this definitely comes under (way under) the rubric of
"not sufficiently broken".

So if you are saying you don't totally agree that it should be there,
fair enough, if you are saying you don't totally agree that now that it
is there it makes no sense to move it, then that's a much harder position
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