Version 1.6 of ai12s/ai12-0448-1.txt

Unformatted version of ai12s/ai12-0448-1.txt version 1.6
Other versions for file ai12s/ai12-0448-1.txt

!standard 10.2(2/5) 22-12-13 AI12-0448-1/02
!standard 10.2(3)
!standard 10.2(4)
!standard 10.2(5)
!standard 10.2(6/2)
!standard 10.2(6.1/2)
!standard 10.2(9)
!class binding interpretation 22-11-30
!status Amendment 1-2012 22-12-09
!status ARG Approved 13-0-0 23-01-19
!status work item 22-11-30
!status received 22-11-04
!priority Low
!difficulty Easy
!qualifier Clarification
!subject Fixes for Terms and Definitions
!summary
Make various changes to the Terms and Definitions subclause.
!question
We have received various complaints from the ISO editors (see below). Should we fix these? (Yes.)
!recommendation
(See Summary.)
!wording
In 1.3.1:
limited type
type for which copying (such as in an assignment_statement) is not allowed
Note: [A nonlimited type is a type for which copying is allowed.]{All types are either limited types or nonlimited types.}
[ISO comment: The term and definition were given in a note to entry, as a result, this term has been added to the document.]
[Editor's note: This bothered me when I created this section.]
----
{nonlimited type type for which copying is allowed}
[Editor's note: See previous item.]
----
nominal subtype [of a view of an object]
the subtype specified when {a}[the] view {of an object} is defined
[ISO comment: ""nominal subtype of a view of an object" is not used in this document. The document uses the following: nominal subtype of the view nominal subtype of the object Please either use “nominal subtype of a view of an object ” in the text or delete term entry altogether.] [Editor: It's better to just define "nominal subtype"; we don't use it for anything else.]
----
progenitor[ of a derived type]
[one of the types]{type} given in the {interface list, if any,}[definition] of {an interface, task, protected, or}[the] derived type {definition}[other than the first]
Note: A progenitor is always an interface type.[ Interfaces, tasks, and protected types can also have progenitors.]
[ISO comment: ""progenitor of a derived type" This term is not used in the document. Please either use in the document or delete entry."] [Editor: It's better to just define "progenitor", there is no other use. To do this, we need to generalize the definition. The formal definition is "a type given in an interface_list", but that's not descriptive enough. We came up with the longer version given above. I also considered "a type that is an ancestor of an interface, task, protected, or derived type, other than a derived type", but that is makes the definitions of ancestor and progenitor depend on each other, so that's not acceptable.]
----
synchronized[ entity]
[entity that ]can be safely operated on by multiple tasks concurrently
{Note: Synchronized is used to qualify entities, as in a synchronized interface.}
[ISO comment: ""Synchronized entity" This term is not used in the document. Please either use in the document or delete entry."]
[Editor: We change the definition to just "synchronized"; this is a qualifer for various kinds of entities.]
----
[type invariant
see invariant]
[Editor: This does not appear to be allowed. It seems unnecessary anyway (and it is in the index). So we just delete it.]
In 1.3.3:
needed compilation unit
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
[ISO comment: ""needed compilation unit" This term is not used in the document. Please either use in the document or delete entry. The document uses “The compilation units needed by a given compilation unit”]
[Editor: Generally, "needed" and "compilation units" are separated by other words. We can't just define "needed", as that would interfere with other uses. The easiest thing to do is to change some of the wording to use the term exactly as written. That is proposed below. An alternative is shown in the !discussion.]
Modify 10.2(2/5):
A partition is a program or part of a program that can be invoked from outside the Ada implementation. For example, on many systems, a partition can be an executable file generated by the system linker. The user can explicitly assign library units to a partition. The assignment is done in an implementation-defined manner. The compilation units included in a partition are those of the explicitly assigned library units, as well as other compilation units needed by those library units. The compilation units needed by a given compilation unit {(the needed compilation units)} are determined as follows (unless specified otherwise via an implementation-defined pragma, or by some other implementation-defined means):
Modify 10.2(3):
* A compilation unit {is a needed compilation unit of}[needs] itself;
Modify 10.2(4):
* If a compilation unit is {among the} needed {compilation units}, then so are any compilation units upon which it depends semantically;
Modify 10.2(5):
* If a library_unit_declaration is {among the} needed {compilation units}, then so is any corresponding library_unit_body;
Modify 10.2(6/2):
* If a compilation unit with stubs is {among the} needed {compilation units}, then so are any corresponding subunits;
Modify 10.2(6.1/2):
* If the (implicit) declaration of the limited view of a library package is {among the} needed {compilation units}, then so is the explicit declaration of the library package.
Modify 10.2(9):
The order of elaboration of library units is determined primarily by the elaboration dependences. There is an elaboration dependence of a given library_item upon another if the given library_item or any of its subunits depends semantically on the other library_item. In addition, if a given library_item or any of its subunits has a pragma Elaborate or Elaborate_All that names another library unit, then there is an elaboration dependence of the given library_item upon the body of the other library unit, and, for Elaborate_All only, upon each library_item {that is a }needed {compilation unit of}[by] the declaration of the other library unit.
-------------------------
private type
view of a type that reveals only some of its properties
Note: 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.
[Editor's note: "full view" is not defined here (nor is partial view). We should at least define "full view" and probably "partial view", and redefine "private type". We also should define "full type" for consistency. This would look like:]
full view
view of a type that reveals all of its properties
Note: There can be other views of the type that reveal fewer properties.
partial view
view of a type that reveals only some of its properties
Note: The remaining properties are defined by the full view given elsewhere.
private type
type that defines a partial view
Note: Private types can be used for defining abstractions that hide unnecessary details from their clients.
full type
type that defines a full view
[Editor's note: After doing the above, the definition of "incomplete type" looks weird. Best to split it, too, giving the following.]
incomplete type type that defines an incomplete view Note: Incomplete types can be used for defining recursive data structures.
incomplete view view of a type that reveals minimal properties
Note: The remaining properties are defined by the full view given elsewhere.
!discussion
ISO requires the exact phrase defined to appear somewhere in the body of the text. There are a few that do not.
Additionally, there are a number of terms defined in notes; those need to be separately defined.
Finally, there is a "type invariant, see invariant" definition; that isn't allowed.
--------------------------
Additional terms that are mentioned in definitions or notes but not defined include:
* allocator (in aliased view, object, storage pool object) * instantiation (in generic instance) * subsystem (in library unit) * derivation class (in derived types, but might be sufficiently defined by "class of types")
Other important terms that probably ought to be defined include:
* child unit * operative constituent * erroneous execution * bounded error
and a number of visibility terms:
* denotes * statically denotes * statically names * homograph * overloaded
We probably can wait on these unless ISO complains (they haven't to date). But we should plan on adding these in an AI22.
------
The JTC1 Directives, Part 2 strictly ban recursive definitions. We have the following:
ancestor of a type
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
ISO hasn't detected this yet (perhaps because in their strict constructionist view, "ancestors" and "ancestors of a type" are different things), but we should plan to fix it somehow in an AI22 (rather than waiting for ISO to drop this on us).
------
An alternative to rewording some of the text in 10.2 would be to define "needed" with the domain given in angle brackets before the definition. (This is specifically allowed by the Directives.) We currently have two such uses of "needed" (the other being "needed component"). This would look like:
needed [component] {<component>} component of a record type or record extension that is required to have its value specified within a given aggregate
needed [compilation unit]
<compilation unit> 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
If this was done, we would not need any of the 10.2 changes.
!comment Terms and Definitions are completely new and do not appear in the
!comment Amendment text, thus there are no !corrigendum sections for them.
!corrigendum 10.2(2/5)
!comment The change of AI12-0439-1 is included here; there is no conflict item.
@drepl A partition is a program or part of a program that can be invoked from outside the Ada implementation. For example, on many systems, a partition might be an executable file generated by the system linker. The user can @i<explicitly assign> library units to a partition. The assignment is done in an implementation-defined manner. The compilation units included in a partition are those of the explicitly assigned library units, as well as other compilation units @i<needed by> those library units. The compilation units needed by a given compilation unit are determined as follows (unless specified otherwise via an implementation-defined @fa<pragma>, or by some other implementation-defined means): @dby A partition is a program or part of a program that can be invoked from outside the Ada implementation. For example, on many systems, a partition can be an executable file generated by the system linker. The user can @i<explicitly assign> library units to a partition. The assignment is done in an implementation-defined manner. The compilation units included in a partition are those of the explicitly assigned library units, as well as other compilation units @i<needed by> those library units. The compilation units needed by a given compilation unit (the @i<needed compilation units>) are determined as follows (unless specified otherwise via an implementation-defined @fa<pragma>, or by some other implementation-defined means):
!corrigendum 10.2(3)
Replace the paragraph:
by:
!corrigendum 10.2(4)
Replace the paragraph:
by:
!corrigendum 10.2(5)
Replace the paragraph:
by:
!corrigendum 10.2(6/2)
Replace the paragraph:
by:
!corrigendum 10.2(6.1/2)
Replace the paragraph:
by:
!corrigendum 10.2(9)
Replace the paragraph:
The order of elaboration of library units is determined primarily by the elaboration dependences. There is an elaboration dependence of a given library_item upon another if the given library_item or any of its subunits depends semantically on the other library_item. In addition, if a given library_item or any of its subunits has a pragma Elaborate or Elaborate_All that names another library unit, then there is an elaboration dependence of the given library_item upon the body of the other library unit, and, for Elaborate_All only, upon each library_item needed by the declaration of the other library unit.
by:
The order of elaboration of library units is determined primarily by the elaboration dependences. There is an elaboration dependence of a given library_item upon another if the given library_item or any of its subunits depends semantically on the other library_item. In addition, if a given library_item or any of its subunits has a pragma Elaborate or Elaborate_All that names another library unit, then there is an elaboration dependence of the given library_item upon the body of the other library unit, and, for Elaborate_All only, upon each library_item that is a needed compilation unit of the declaration of the other library unit.
!ASIS
No ASIS effect.
!ACATS test
No ACATS tests are needed, these changes are not intended to have any semantic effect.
!appendix

From: Tucker Taft
Sent: Thursday, January 5, 2023  9:19 AM

One suggestion for the next language revision: we should probably include a
definition of "predicate" in the Terms and Definitions.

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

Questions? Ask the ACAA Technical Agent