AI22-0063-1/03

AI22-0063-1

!standard 3.11.1(1/3) 23-06-07 AI22-0063-1/03

!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

!summary

** TBD.

!issue

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.

A somewhat related confusion arises from the term “declaration”. Is a subprogram_body a declaration? Only when it is not a completion? Not clear… In C they distinguish “declaration” from “definition” (though not always with crystal clarity). Ada has hijacked the term “definition” to be a declaration omitting the part that introduces a new identifier.

In any case, Ada should minimize confusing usages of terms. Note that we are not ruling out using reserved words in a semantic sense, so long as there is no possibility of confusion. In fact, we would like to have a general equivalence between a syntactic term and the term without underscores, and have them mean the same thing.

The following terms have been identified for potential disambiguation:

body

Syntactic term – 3.11(5)

body ::= proper_body | body_stub
proper_body ::=
subprogram_body | package_body | task_body | protected_body

Semantic term – 3.11.1(1)

A body is a body, an entry_body, a null_procedure_declaration or an expression_function_declaration that completes another declaration, or a renaming-as-body (see 8.5.4).

Probably change the “body” syntactic term – it is not used very often in the standard.

Simplest might be “body_item”.

function_call vs. function call

Could simply require “call of a function” (or just “call”) vs. “function_call”
Perhaps “invocation of …” rather than “call of …”?

Could apply to procedures as well, though there is less confusion here

aspect_specification vs aspect specification

Could simply require “specification of an aspect” vs. “aspect_specification”
Perhaps “definition of an aspect” rather than “specification of an aspect”

Even though there is a syntactic construct “aspect_definition” saying “definition of an aspect” seems less likely to create confusion, whereas “specification” strongly links to the aspect_specification syntactic construct.

access parameter vs. access type parameter

Not clear it is worth making a change here
We could use the term “anonymous access parameter” though that is a bit misleading. “anonymous access type parameter” would probably be clearest. But then we might have to always say “named access type parameter” when we want to exclude the ones of an anonymous type.
Similar considerations apply to “access discriminant” vs. “discriminant of an access type”

Use of the word “actual”

As a term, it has a very specific semantic meaning (formal vs actual), but as a regular English word, it has a much more general meaning. Unfortunately sometimes it can be unclear which one it is. Perhaps use “true” when not referring to the semantic term.
Worse still, there are terms such as “actual subtype” 3.3(23/5) that do not have a corresponding “formal subtype” term at all. And while “formal subtype” appears in various places and has an obvious meaning, it does not actually seem to be related to the term “actual subtype”.

In particular, in this case the term "actual" is in contrast to "nominal."

Actions

Sometimes referring to tasking constructs/semantics
Other times referring to executable constructs
“Protected action” vs “sequence of actions” for a sequence of statements (introduction)

Eg. “Runtime Actions” (1.3.4)

Maybe “sequence of actions” is redundant vis-a-vis sequence of statements
This might not be a significant enough source of confusion to really warrant any changes.

Item

This may be a “nothingburger”. However the use of this word in terms, syntax, and semantics is prevalent. It seems it often carries a very specific meaning sometimes, but that meaning is very inconsistent.
As a syntactic category, it generally seems to appear in constructs that are part of some list.
Sometimes they refer to constructs of wildly different scales

“Representation item” -> “context item” -> “task item” -> “library item”

“The items in a for loop” 3.2.4(14.b/4)
Sometimes appearing to be used as a synonym for “object” - see:

3.7.1(7.a/2) - thou shalt not create an access subtype that can point to an item whose discriminants can be changed by assignment”.
3.9(12.c/2) - … used by T'Class'Output to determine whether the item being written is at the same accessibility level as T.

!recommendation

(See Summary.)

!wording

** TBD.

!discussion

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