!standard 1.3(0) 22-06-01 AI12-0443-1/03 !standard N(0) !class presentation 22-04-25 !status Amendment 1-2012 22-05-05 !status ARG Approved 14-0-0 22-05-05 !status work item 22-04-25 !status received 22-02-28 !priority Critical !difficulty Medium !qualifier Omission !subject Convert the glossary into a separate Terms and Definitions clause !summary To conform to ISO formatting requirements, we move and restructure the glossary to serve as the Terms and Definitions clause. !question ISO requires that important terms be gathered into a Terms and Definitions clause (see comment #13 and #14). We define most terms in context within the document, but we have created a relatively comprehensive glossary, which could be the basis for such a chapter. Should we move the glossary into the Terms and Definitions clause? (Yes.) !recommendation Turn the glossary into the Terms and Definitions clause. !wording [Editor's note: In this AI, we use Ada Reference Manual numbering unless otherwise specified.] Delete Annex N (the Glossary) in its entirity. Augment subclause 1.3 (Clause 3 in the ISO standard), Terms and Definitions, with the following definitions: • Types, Objects, and their Properties [Group T] * abstract type. a tagged type intended for use as an ancestor of other types, but which is not allowed to have objects of its own * access type. a type that has values that designate aliased objects * Note 1 on entry: Access types correspond to “pointer types” or “reference types” in some other languages. * accessibility level. a representation of the lifetime of an entity in terms of the level of dynamic nesting within which the entity is known to exist * aliased view. a view of an object that can be designated by an access value * Note 1 on entry: Objects allocated by allocators are aliased. Objects can also be explicitly declared as aliased with the reserved word aliased. The Access attribute can be used to create an access value designating an aliased object. * ancestor of a type. the type itself or, in the case of a type derived from other types, its parent type or one of its progenitor types or one of their ancestors * Note 1 on entry: Ancestor and descendant are inverse relationships. * array type. a composite type whose components are all of the same type * aspect. a specifiable property of an entity * Note 1 on entry: An aspect can be specified by an aspect_specification on the declaration of the entity. Some aspects can be queried via attributes. * attribute. a characteristic or property of an entity that can be queried, and in some cases specified * category of types. a set of types with one or more common properties, such as primitive operations * Note 1 on entry: A category of types that is closed under derivation is also known as a class. * character type. an enumeration type whose values include characters * class of types. a set of types that is closed under derivation, which means that if a given type is in the class, then all types derived from that type are also in the class * Note 1 on entry: The set of types of a class share common properties, such as their primitive operations. * class-wide type. a type that represents all of the types derived, directly or indirectly, from a given specific type * Note 1 on entry: An object of a class-wide tagged type can be used in a dispatching call; the tag of the object determines which subprogram body to invoke. * composite type. a type with components, such as an array or record * container. a structured object that represents a collection of elements all of the same (potentially class-wide) type, such as a vector or a tree * Note 1 on entry: Several predefined container types are provided by the children of package Ada.Containers (see A.18.1). * controlled type. a type that supports user-defined assignment and finalization * Note 1 on entry: Objects are always finalized before being destroyed. * default initial condition. a property that holds for every default-initialized object of a given type * derived type. a type defined in terms of a parent type and zero or more progenitor types given in a derived type definition * Note 1 on entry: A derived type inherits properties such as components and primitive operations from its parent and progenitors. * Note 2 on entry: A type together with the types derived from it (directly or indirectly) form a derivation class. * descendant of a type. the type itself or a type derived (directly or indirectly) from it * Note 1 on entry: Descendant and ancestor are inverse relationships. * discrete type. a type that is either an integer type or an enumeration type * discriminant. a parameter for a composite type, which can control, for example, the bounds of a component that is an array * Note 1 on entry: A discriminant for a task type can be used to pass data to a task of the type upon its creation. * dispatching subprogram. a primitive operation of a tagged type * Note 1 on entry: Dispatching subprograms provide run-time polymorphism. A dispatching subprogram can be called with statically tagged operands, in which case the subprogram body invoked is determined at compile time. Alternatively, a dispatching subprogram can be called using a dispatching call, in which case the subprogram body invoked is determined at run time. * elementary type. a type that does not have components * enumeration type. a type defined by an enumeration of its values, which can be denoted by identifiers or character literals * incomplete type. a view of a type that reveals only a few of its properties * Note 1 on entry: The remaining properties are provided by the full view given elsewhere. * Note 2 on entry: Incomplete types can be used for defining recursive data structures. * indexable container type. a type that has user-defined behavior for indexing, via the Constant_Indexing or Variable_Indexing aspects * integer type. a type that represents signed or modular integers * Note 1 on entry: A signed integer type has a base range that includes both positive and negative numbers, and has operations that can raise an exception when the result is outside the base range. A modular type has a base range whose lower bound is zero, and has operations with “wraparound” semantics. Modular types subsume what are called “unsigned types” in some other languages. * interface type. an abstract tagged type that has no components or concrete operations except possibly null procedures * Note 1 on entry: Interface types are used for composing other interfaces and tagged types and thereby provide multiple inheritance. Only an interface type can be used as a progenitor of another type. * invariant. an assertion that is expected to be True for all objects of a given private type when viewed from outside the defining package * iterable container type. a type that has user-defined behavior for iteration, via the Default_Iterator and Iterator_Element aspects * limited type. a type for which copying (such as in an assignment_statement) is not allowed * Note 1 on entry: A nonlimited type is a type for which copying is allowed. * needed component. a component of a record type or record extension that is required to have its value specified within a given aggregate * needs finalization. a type whose objects require additional actions performed at the point when they cease to exist * Note 1 on entry: Any type with a part that is a task, a protected object, or a controlled object needs finalization. * nominal subtype of a view of an object. the subtype specified when the view is defined * object. an entity that contains a value, and is either a constant or a variable * Note 1 on entry: An object is created by an object_declaration or by an allocator. A formal parameter is (a view of) an object. A subcomponent of an object is an object. * operational aspect. an aspect that indicates a logical property of an entity, such as the precondition of a subprogram, or the procedure used to write a given type of object to a stream * parent of a derived type. the first ancestor type given in the definition of the derived type * Note 1 on entry: The parent can be almost any kind of type, including an interface type. * predicate. an assertion that is expected to be True for all objects of a given subtype * primitive operations of a type. the operations (such as subprograms) declared together with the type declaration * Note 1 on entry: Primitive operations are inherited by other types in the same derivation class of types. * private extension. a type that extends another type, with the additional properties hidden from its clients * private type. a view of a type that reveals only some of its properties * Note 1 on entry: The remaining properties are provided by the full view given elsewhere. Private types can be used for defining abstractions that hide unnecessary details from their clients. * progenitor of a derived type. one of the types given in the definition of the derived type other than the first * Note 1 on entry: A progenitor is always an interface type. Interfaces, tasks, and protected types can also have progenitors. * protected type. a composite type whose components are accessible only through one of its protected operations, which synchronize concurrent access by multiple tasks * real type. a type that has values that are approximations of the real numbers * Note 1 on entry: Floating point and fixed point types are real types. * record extension. a type that extends another type optionally with additional components * record type. a composite type consisting of zero or more named components, possibly of different types * reference type. a type that has user-defined behavior for “.all”, defined by the Implicit_Dereference aspect * representation aspect. an aspect that indicates how an entity is mapped onto the underlying hardware, for example the size or alignment of an object * scalar type. either a discrete type or a real type * specific type. an individual type within a class of types, as distinguished from a class-wide type or a universal type * stable property. a characteristic associated with objects of a given type that is preserved by many of the primitive operations of the type * storage pool object. an object associated with one or more access types from which the storage for objects created by allocators of the access type(s) is obtained * Note 1 on entry: Some storage pools can be partitioned into subpools in order to support finer-grained storage management. * stream. a sequence of elements that can be used, along with the stream-oriented attributes, to support marshalling and unmarshalling of values of most types * subtype. a type together with optional constraints, null exclusions, and predicates, which constrain the values of the type to the subset that satisfies the implied conditions * synchronized entity. an entity that can be safely operated on by multiple tasks concurrently * Note 1 on entry: A synchronized interface can be an ancestor of a task or a protected type. Such a task or protected type is called a synchronized tagged type. * tagged type. a type whose objects each have a run-time type tag, which indicates the specific type for which the object was originally created * Note 1 on entry: Tagged types can be extended with additional components. * task type. a composite type used to represent active entities which execute concurrently and that can communicate via queued task entries * Note 1 on entry: The top-level task of a partition is called the environment task. * type. a defining characteristic of each object and expression of the language, with an associated set of values, and a set of primitive operations that implement the fundamental aspects of its semantics * Note 1 on entry: Types are grouped into categories. Most language-defined categories of types are also classes of types. * type invariant. see Invariant * universal type. a type that can be implicitly converted to or from all the types within a given class of elementary types * Note 1 on entry: There are four universal types – universal integer, universal real, universal fixed, and universal access. * view of an entity. a representation of an entity that reveals some or all of the properties of the entity * Note 1 on entry: A single entity can have multiple views. • Subprograms and their Properties [Group S] * function. a form of subprogram that returns a result and can be called as part of an expression * overriding operation. an operation that replaces an inherited primitive operation * Note 1 on entry: Operations can be marked explicitly as overriding or not overriding. * postcondition. an assertion that is expected to be True when a given subprogram returns normally * precondition. an assertion that is expected to be True when a given subprogram is called * procedure. a form of subprogram that does not return a result and can only be invoked by a statement * subprogram. a unit of a program that can be brought into execution in various contexts, with the invocation being a subprogram call that can parameterize the effect of the subprogram through the passing of operands * Note 1 on entry: There are two forms of subprograms: functions, which return values, and procedures, which do not. • Other Syntactic constructs [Group C] * aggregate. a construct used to define a value of a composite type by specifying the values of the components of the type * compilation unit. a program unit that is separately compiled * Note 1 on entry: A compilation_unit contains either the declaration, the body, or a renaming of a program unit. * construct. a piece of text (explicit or implicit) that is an instance of a syntactic category defined under “Syntax” * container aggregate. a construct used to define a value of a type that represents a collection of elements, by explicitly specifying the elements in the collection * core language. a clause or annex in which are defined language constructs or capabilities that are provided by all conforming implementations * Note 1 on entry: A construct is said to be part of the core language if it is defined in a core language clause or annex. * declaration. a language construct that associates a name with (a view of) an entity * Note 1 on entry: A declaration can appear explicitly in the program text (an explicit declaration), or can be supposed to occur at a given place in the text as a consequence of the semantics of another construct (an implicit declaration). * generic unit. a template for a (nongeneric) program unit * Note 1 on entry: The template can be parameterized by objects, types, subprograms, and packages. * Note 2 on entry: Generic units can be used to perform the role that macros sometimes play in other languages. * generic instance. a nongeneric unit created by the instantiation of a generic unit * iterator. a construct that is used to loop over the elements of an array or container * Note 1 on entry: Iterators can be user defined, and can perform arbitrary computations to access elements from a container. * iterator filter. a construct that is used to restrict the elements produced by an iteration to those for which a boolean condition evaluates to True * library unit. a separately compiled program unit, which is a package, a subprogram, or a generic unit * Note 1 on entry: Library units can have other (logically nested) library units as children, and can have other program units physically nested within them. A root library unit, together with its children and grandchildren and so on, form a subsystem. * master construct. one of certain executable constructs for which there can be objects or tasks whose lifetime ends when the construct completes * Note 1 on entry: Execution of a master construct is a master, with which objects and tasks are associated for the purposes of waiting and finalization. * needed compilation unit. a compilation unit that is necessary to produce an executable partition, because some entity declared or defined within the unit is used elsewhere in the partition * package. a program unit that defines the interface to a group of logically related entities, along with their implementation * Note 1 on entry: Typically, a package contains the declaration of a type (often a private type or private extension) along with the declarations of primitive subprograms of the type, which can be called from outside the package, while their inner workings remain hidden from outside users. * parallel construct. an executable construct that defines multiple activities of a single task that can proceed in parallel, via the execution of multiple logical threads of control * partition. a part of a program, which consists of a set of interdependent library units * Note 1 on entry: Each partition can run in a separate address space, possibly on a separate computer. A program can contain just one partition, or it can be distributed across multiple partitions, which can execute concurrently. * pragma. a compiler directive to provide control over and above that provided by the other syntactic constructs of the language * Note 1 on entry: There are language-defined pragmas that give instructions for optimization, listing control, etc. An implementation can support additional (implementation-defined) pragmas. * program. a set of partitions, each of which can execute in a separate address space, possibly on a separate computer * program unit. a language construct that is a package, a task unit, a protected unit, a protected entry, a generic unit, or an explicitly declared subprogram other than an enumeration literal * Note 1 on entry: Certain kinds of program units can be separately compiled. Alternatively, they can appear physically nested within other program units. * reduction expression. an expression that defines how to map or transform a collection of values into a new set of values, and then summarize the values by applying an operation to reduce the set to a single value * renaming. a declaration that does not define a new entity, but instead defines a new view of an existing entity * specialized needs annex. an annex in which are defined language constructs or capabilities that are not necessarily provided by all conforming implementations * subunit. the body of a program unit that can be compiled separately from its enclosing program unit • Runtime Actions [Group R] * assertion. a boolean expression that is expected to be True when evaluated at certain specified places * Note 1 on entry: Certain pragmas and aspects define various kinds of assertions. * elaboration. the process by which a declaration achieves its run-time effect * Note 1 on entry: Elaboration is one of the forms of execution. * evaluation. the process by which an expression achieves its run-time effect * Note 1 on entry: Evaluation is one of the forms of execution. * execution. the process by which a construct achieves its run-time effect * Note 1 on entry: Execution of a declaration is also called elaboration. Execution of an expression is also called evaluation. * logical thread of control. an activity within the execution of a program that can proceed in parallel with other activities of the same task, or of separate tasks * master. the execution of a master construct * Note 1 on entry: Each object and task is associated with a master. When a master is left, associated tasks are awaited and associated objects are finalized. • Exceptional Situations [Group E] * check. a test made during execution to determine whether a language rule has been violated * exception. a kind of exceptional situation * exception occurrence. a run-time occurrence of an exceptional situation * handle an exception. performing some actions in response to the arising of an exception * raise an exception. to abandon normal program execution so as to draw attention to the fact that the corresponding situation has arisen * suppress a check. to assert that the check cannot fail, and to request that the compiler optimize by disabling the check * Note 1 on entry: The compiler is not required to honor this request. Suppressing checks that can fail can cause a program to behave in arbitrary ways. !discussion The glossary is adequate to form the basis for the required Terms and Definitions clause. In the Ada Reference Manual, it will be added to section 1.3 Terms and Definitions. In the ISO standard it will be its own clause. For the ISO version, we will use the boilerplate required by ISO instead of the current text in 1.3. An alternative that would still be responsive to the ISO comment would be to put the above into the ISO FDIS but do nothing to the Ada Reference Manual, including leaving the Glossary as it is. That would complicate future maintenance somewhat (since the Glossary and the T&D would both need to be updated when either is, and the wording is somewhat different between them). As such, we suggest the simpler long-term solution. [Editor's note: The Webster's dictionary reference isn't the one allowed anymore. It's "Webster’s New World College Dictionary" in the latest Directives; we ought to consider changing the reference to that. OTOH, since the dictionary won't appear in the ISO version, doing nothing is acceptable.] !example None needed. !ACATS test No tests required. !appendix From: Randy Brukardt Sent: Friday, June 10, 2022 1:03 AM I've finished added the new Terms and Definitions to the RM, and following are some fixes to that AI. There were also a few typos in the AI (stray brackets, leftover Editor's notes) that I didn't keep track of. Please tell me if you disagree with any of these or would like any changes. I'm hoping to "freeze" this work on Monday (I don't think I'll finish it tomorrow, but it's possible), so I need comments ASAP. --- We have: * declaration. A declaration is a language construct that associates a name with (a view of) an entity. A declaration may appear explicitly in the program text (an explicit declaration), or may be supposed to occur at a given place in the text as a consequence of the semantics of another construct (an implicit declaration). This is the glossary style, not rewritten into appropriate Term style. (The repeat of the term and the punctuation at the end is a giveaway.) We're also misusing "may" here (there's no permission, it's about possibility.) I replaced this with: * declaration. a language construct that associates a name with (a view of) an entity * Note 1 on entry: A declaration can appear explicitly in the program text (an explicit declaration), or can be supposed to occur at a given place in the text as a consequence of the semantics of another construct (an implicit declaration). ----- We have both "private type" and "incomplete type" with the exact same definition: a view of a type that reveals only some of its properties While technically true, it is likely to be confusing to someone. So I changed the definition of incomplete types slightly: a view of a type that reveals only a few of its properties Hopefully, it is obvious that "a few" < "some". :-) ----- AI12-0443-1 does not include the term "compilation unit", even though it appeared in the glossary and is used in other definitions. That may have been because a direct translation of the glossary entry doesn't work as a definition. It seems important to have this term for completeness, so I took a cue from the definition of "program unit" and added it as follows: * compilation unit. a program unit that is separately compiled * Note 1 on entry: A compilation_unit contains either the declaration, the body, or a renaming of a program unit. ----- In AI12-0443-1, we have a subclause heading: . Run-time Actions But we generally (but not always) write this as "Runtime", especially when it is used as a modifier, as it is here. (For some reason, we have "runtime check" and "run-time effect". Yuck.) So I've changed this to: . Runtime Actions ----- In AI12-0443-1, we have a new definition: * needed compilation unit. a compilation unit that is needed to produce an executable partition, because some entity declared or defined within the unit is used elsewhere in the partition But we shouldn't use part of a term to define the term if at all possible. So I replaced "needed" by "necessary" in the definition: * needed compilation unit. a compilation unit that is necessary to produce an executable partition, because some entity declared or defined within the unit is used elsewhere in the partition ---- In AI12-0443-1, we are missing a definition for "assertion", a term that is used in the definition of a number of other terms, and one that was defined in the Glossary. The Glossary definition is not very useful, and enumerates the kinds of assertions (and leaves out the new Ada 2022 assertions). The part of it that would become a note is a better definition, so I swapped and generalized them: So I replaced the entire thing with: * assertion. a boolean expression that is expected to be True when evaluated at certain specified places * Note 1 on entry: Certain pragmas and aspects define various kinds of assertions. I put this into the "runtime actions" group, as it seemed like the best fit (in doing so, I slightly changed the wording from "at runtime" to "when evaluated" to better fit the grouping). ----- There are other terms that seem missing in AI12-0443-1. Most of these are mentioned in notes, some even as a sort of definition (which definitely should not be in a note for some other term). I mention them for completeness and possible future work, rather than to do anything now: * allocator * subsystem * nonlimited type * derivation class * full view of a type * child unit * operative constituent * instantiation We don't have much about visibility here, either. Terms like "denotes", "static denotes", "statically names", "homograph", "overloaded" and so on are not here (or in the old glossary). It also would make sense to define "erroneous execution" and "bounded error", since they are so commonly used. [Note: It would not be a big deal to add some or all of these now, BUT I would need proposed wording by Monday. If someone feels a strong urge, feel free to try. I note that Tucker did add a few terms, mostly in the exception handling section, so it certainly is OK to do so.] ---- I propose adding the following AARM note to RM 1.3 to better explain the differences between the definitions found in 1.3 and those found in the body of the RM. (Since this is an AARM note, it has nothing to do with the ISO version.) AARM Discussion: The definitions found here are short, descriptive definitions. These are most useful for comprehension when an exact meaning is not needed. More formal, detailed definitions are found in the body of the RM; these are needed to determine the exact application of rules to constructs and entities. To see the difference, consider "aliased view". The descriptive definition is "a view of an object that can be designated by an access value". The formal definition is a lengthy paragraph in 3.10 that defines 10 separate constructs as aliased views. In order to reason about a language rule that requires an aliased view in a particular context, one needs to look at the list of constructs in order to determine if the object in hand is actually an aliased view. The descriptive definition is no help in this case. End AARM Discussion. **** I would have used "variable" as the example, but I did not as we don't have it in the list of terms; and given the intent not to define "common terms, which a qualified user of the document will already know", it probably should not be there. **************************************************************** From: Tucker Taft Sent: Friday, June 10, 2022 6:36 AM All of your suggestions make sense to me. Thanks for doing all this work... **************************************************************** From: Gary Dismukes Sent: Friday, June 10, 2022 12:38 PM > In AI12-0443-1, we have a subclause heading: > > . Run-time Actions > > But we generally (but not always) write this as "Runtime", especially > when it is used as a modifier, as it is here. (For some reason, we > have "runtime check" and "run-time effect". Yuck.) So I've changed this to: > > . Runtime Actions The RM is definitely still inconsistent here, but when I search the Ada 2022 RM I only get 9 instances of the unhyphenated form "runtime", but 69 instances of the hyphenated form "run-time" (with the hyphen). (There are also 31 cases of "run time", which are hopefully all cases where we're referring to the time at which something is run, but I didn't check them.) So I'm not sure why you say that we generally use the form "runtime". **************************************************************** From: Randy Brukardt Sent: Monday, June 13, 2022 3:13 PM Humm. I see a lot more "runtime"s than that (I counted 15 now, and there are more in the index and generated annexes, which I probably counted the other day). And I see some "run-time"s, roughly the same number, but I did not count the generated header "Bounded (Run-Time) Errors". So to me it appeared to be a wash (without making a formal count). But I recall a discussion a few years ago where we researched and determined that "runtime" is preferred in new text. So that's what I've been using. I'd replace them all, but that seems like unnecessary churn. I would consider changing the generated header (I'm changing other generated headers today anyway), but it's probably a bit late this time to do that- probably ought to let everyone weigh in. **************************************************************** From: Jeff Cousins Sent: Monday, June 13, 2022 3:32 AM I thought Tuck had a distinction between "xyz happens at runtime" and "the runtime" (system), not that I remember which had a hyphen and which didn't. **************************************************************** From: Randy Brukardt Sent: Monday, June 13, 2022 8:59 PM >I thought Tuck had a distinction between "xyz happens at runtime" and >"the runtime" (system), not that I remember which had a hyphen and >which didn't. There is a distinction, but neither has a hyphen. "run time" is an actual time, and is written with two words (and a space). Made-up words don't have hyphens (as in our regular rules), and thus the modifier "runtime" (which is mainly an identifier, and not referring to a specific time) does not have a hyphen. But, on top of that, we also have on-line references that suggest that "runtime" is now preferred for all uses. I personally like that, since I've used the spelling "runtime" pretty much from the beginning of my career (a look at the AI !appendixes shows that clearly :-). I tried to find the reference to that discussion, but I can't find it in large part because so many of us write "runtime" as a matter of course. There's a *lot* of "runtime"s in the AI12's and the associated mail. (It's also possible that the thread was not recorded anywhere.) **************************************************************** From: Randy Brukardt Sent: Friday, June 10, 2022 1:03 AM **************************************************************** From: Randy Brukardt Sent: Friday, June 10, 2022 1:03 AM **************************************************************** From: Randy Brukardt Sent: Friday, June 10, 2022 1:03 AM ****************************************************************