!standard 3.11.1(1/3)                                        23-03-20  AI22-0063-1/01

!standard 6.6(2)

!standard 13.11.4(31/3)

!class binding interpretation 23-03-20

!status work item 23-02-20

!status received 23-02-20

!priority Low

!difficulty Easy

!qualifier Clarification

!subject Font alone should not differentiate terms


** TBD.


Ada has places where the typography of a work or phrase is significant. For instance, body refers to the reserved word body; body refers to the syntax body; and body refers to the semantic term body. The latter includes the syntax body as well as some additional constructs.

These usages cause confusion for readers, especially when the Reference Manual is rendered by alternative means (an obvious example being plain text, but also in the typography required by standards organizations). Moreover, they violate recommendations for usability by the visually impaired (often referred to as "accessibility" of documents, a term we'll avoid here because of its Ada meaning). In some cases, these are even legal requirements.

For all of these reasons, Ada should eliminate confusing usages of terms.


(See Summary.)


** TBD.


Changing reserved words would of course be a massive incompatibility, so we can only consider modifying terms or syntax definitions to eliminate these confusions. It would be best to minimize changes needed, so it is necessary to determine the changes to make on a case-by-case basis.


A related issue stems from the unwritten rule that one can refer to an entity semantically by its syntactic name (with any underscores replaced by spaces), without having any formal definition of such a term. For instance, the Reference Manual often uses "assignment statement" to refer to the entity defined by the syntax "assignment_statement". There is no definition of "assignment statement" in the Reference Manual.

This leads to a confusing case when a term is defined that has the same name as a syntax construct. For instance, "function_call" is a syntax construct (a kind of name), while "function call" is a semantic construct including all forms of function calls (including infix operators, which are not names and thus are not function_calls). This difference has bit us in constructing

wording on several occasions.


Someone will need to be assigned to study the entire Ada Reference Manual and determine all of the pairs of terms and syntax that are potentially confusing, and then suggest possible changes for those pairs to eliminate the conflicts.

The AI author suggests that should look something like the following, along with appropriate wording changes once the new terms have been chosen:


body - reserved word

body - syntax construct

body - semantic construct (includes the syntax body and more).

These all have different meanings. We can't change the reserved word for compatibility reasons, so we need to change both of the others.

For the syntax construct, the author does not have a good suggestion. "syntax_body" seems redundant; "formal_body" and "actual_body" seem to imply something about the usage that is not intended; "real_body" seems to imply that there is an imaginary_body somewhere. Maybe just "the_body"?

For the semantic construct, the key is that this is anything that acts as a body, even if it isn't syntactically a body. So we need to say that with a term like "acting body" or "completing body" or "real body".


function_call - syntax construct

function call - semantic construct (includes syntactic function_calls as well

                    as infix operators).

We only need to change one of these. We could change the syntax term to "prefix_function_call" or "named_function_call". Or we could change the semantic term to something like "virtual function call" or "acting function call".

Note that we never actually define the term "function call". Rather, we depend on the fact that an infix operator is "equivalent to a function_call". But it clearly cannot syntactically be a function_call (it is not a name), so as usual the equivalence is not perfect. We'll need to add an explicit definition of whatever term we chose, since once we give these concepts different names, the handwaving no longer works (if it ever did).

!ACATS test

This is only a terminology change, so no tests should need to be changed because of it. It's possible that some comments in existing tests ought to changed to reflect the terminology changes, but that is not necessary - the tests can continue to be used unchanged.


Here we preserve the original ARG emails that identified the issue, or commented on possible solutions.  This section is generally maintained by the project editor (Randy Brukardt currently).