!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 <> 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 <> 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" 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 <> 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. ****************************************************************