!standard 1.1.3 (00) 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 :-) ****************************************************************