Version 1.1 of ais/ai-10284.txt

Unformatted version of ais/ai-10284.txt version 1.1
Other versions for file ais/ai-10284.txt

!standard 2.09 (02)          04-07-19 AI95-00284-02/01
!standard 2.08 (02)
!class amendment 04-07-19
!status work item 04-07-19
!status received 04-07-19
!priority Medium
!difficulty Medium
!subject New reserved words
"interface", "overriding" and "synchronized" are reserved words.
Three new keywords need be added to support the new features of the amendment. AI95-00284-01 proposes the introduction of non-reserved keywords in the language to maintain compatibility with existing programs despite the introduction of the new keywords. This alternative proposes that they be reserved words.
(See summary.)
Add "interface", "overriding" and "synchronized" to the list of reserved words in 2.9.
Change 2.8(2):
pragma ::= pragma identifier [(pragma_argument_association {, pragma_argument_association})];
to: pragma ::= pragma pragma_designator [(pragma_argument_association {, pragma_argument_association})]; pragma_designator ::= identifier | interface
All modern programming languages require that keywords be reserved. Introducing non-reserved keywords would look like a step backwards, and would defeat the argument of Ada being a cleanly defined programming language.
From a pedagogical point of view, it is likely that no teacher will confess the existence of non-reserved keywords, and most users will expect the new keywords to be reserved; as a result, compiler vendors may receive complaints from users because the compiler accepted identifiers that are the same as the new keywords.
Moreover, there are utilities that do only very simple parsing on source code using reg-exps (like pretty printers, Emacs Ada mode, etc.). If an unreserved keyword is used in a program, it may fool such tools. Dealing correctly with unreserved keywords would require these tools to make a much more complicated analysis, possibly involving some semantics.
Upward compatibility is an important goal for the amendment, as it was for the 95 revision. Note that the issue of the impact of new reserved words was discussed at length during the 95 process; at a time, it was suggested to allow identifiers ending with underscores to minimize the effort of adapting programs that used the new 95 reserved words. This was dropped eventually, and although there were six new reserved words, the incompatibility was well accepted by the community. There is no new situation currently that justifies taking a different option.
It is however important to assess the impact of the introduction of new reserved words for programs that currently uses them as identifiers. There is of course no impact for programs that do not use them, we will therefore assess how likely it is that the proposed new keywords be actually used, and in which contexts.
1) Interface
"Interface" was used in Ada83 as the name of a pragma. Although this pragma disappeared from Ada95, many compilers still support it as an implementation defined pragma for upward compatibility. In order not to outlaw pragma Interface, the syntax of a pragma is changed similarly to the syntax of attributes (which can be reserved words).
Apart from this special case, let's consider some cases where "interface" could be used as an identifier.
- As a type identifier One could imagine a package like Hardware_Device declaring a type Interface. However, the non-reserved option would introduce a lot of confusion. For example:
type T is interface; subtype S is interface; type T is new interface;
would all be legal, with totally different meanings!
type interface is interface; type T is interface and interface;
would also be legal.
It is therefore highly likely that programs using such types will quickly change them to a better name in any case. Nothing would be gained by making the keyword non-reserved.
- As a package identifier It seems highly unlikely that an application uses "Interface" for the name of root package, because of the possible confusion with the package Interfaces. It is possible that the name be used for a child package, like Some_Hardware.Interface. However, such usage is likely to be of limited scope, therefore the extent of a modification should be limited.
-As an object identifier The use of "Interface" as a variable or constant name is even less likely. It is generally considered bad practice to have variables declared in package specifications, therefore a change in a variable name is generally very limited in scope. The same does not apply to constants, however the use of "interface" for constants seems even less likely than for variables.
2) Overriding
This identifier has such a specialized meaning that it is unlikely to be found in users' code, except maybe in Ada compilers!
3) Synchronized
This identifier is more likely to be found in users' code. Although this would need to be confirmed by statistics, its probability is presumably equivalent to the use of "protected" in Ada83 programs. Experience has shown that changing it to a form like "Is_Synchronized" (like "Is_Protected" for Ada 95) was deemed acceptable by the community.
Moreover, this keyword has been introduced recently, and is used only for synchronized interfaces. An alternate syntax could be found that does not require a new keyword, like:
type T is task or protected interface;
The AFNOR committee includes a representative of a big french company who conducted a survey of existing code (several hundreds thousands lines); he concluded that the impact of having these keywords reserved was well acceptable, and that he would support this position.
It is also important to note that making the keywords reserved will imply an one-shot modification to existing programs, while having them unreserved may cause permanent problems over the whole lifecycle.
In conclusion, it is highly likely that every reasonable coding standard will forbid the use of unreserved keywords in new programs, and that older programs will be directed to change corresponding identifiers ASAP, even if new keywords are unreserved. For pure legacy programs, compilers may have an option to provide compatibility with Ada95 (as is currently the case for Ada83).
In addition, a free utility (Adasubst) that allows automatic replacement of identifiers in an entire program (based on ASIS, therefore fully accounting for all semantics) is available, therefore reducing the cost of changing identifiers.
Therefore, the benefit of upward compatibility gained by unreserved keywords would be minimal compared to the damages caused to the language.
(See discussion.)
--!corrigendum 02.09(2)
!ACATS test


Questions? Ask the ACAA Technical Agent