!standard 2.09 (02) 02-11-27 AI95-00284/04 !standard 2.09 (03) !class amendment 02-01-23 !status work item (rejected by WG9) 02-12-13 !status ARG Approved 8-1-0 02-06-22 !status work item 02-01-23 !status received 02-01-23 !priority Medium !difficulty Medium !subject Nonreserved keywords !summary A new lexical construct, named "nonreserved keywords" is introduced. It makes it possible to add new syntax without compromising the readability of the language, and without introducing incompatibilities. !problem The addition of new language features for the next revision of Ada appears difficult to do without the addition of new syntax. However, in some cases the addition of new syntax is problematic without new reserved words. Adding new reserved words is probably not an option at this late stage for compatibility reasons, but on the other hand using only existing reserved words can lead to constructs that are hard to understand. Here are two examples from some of the amendments that have recently been discussed by the ARG: type T is abstract; -- This is really an interface a la Java. procedure Finalise (Object : in out Root_Type); pragma Overriding; In both cases, it could be argued that the introduction of new reserved words would make the purpose of the construct more explicit, and would therefore improve the readability of the language: type T is interface; procedure Finalise (Object : in out Root_Type) is overriding; (In the second case a solution based on a pragma has the advantage of being usable in Ada 95, without waiting for the next revision of the language; still, it lacks readability and is more error-prone.) !proposal This amendment introduces a new category of lexical elements, _nonreserved_keywords_. We use the term "keyword" because "nonreserved word" would sound strange. For consistency, the term "reserved word" is changed into "reserved keyword". Examples of nonreserved keywords could be (ignoring upper/lower case distinctions): interface overriding Nonreserved keywords have special meaning in the syntax (where they appear as terminals). They appear in lower case boldface in the RM, just like reserved keywords. Here are two examples of possible BNF productions including nonreserved keywords: type_definition ::= ... | abstract_interface_definition abstract_interface_definition ::= [LIMITED] INTERFACE subprogram_specification ::= PROCEDURE defining_program_unit_name parameter_profile overriding_indication | FUNCTION defining_designator parameter_and_result_profile [overriding_indication] overriding_indication ::= IS OVERRIDING Evidently, the productions which involve nonreserved keywords must be such that they do not make the grammar ambiguous, or do not require unreasonable lookahead. This will have to be checked on a case-by-case basis. An identifier (2.3) may be a nonreserved keyword. This is the rule that ensures that the introduction of new syntax using nonreserved keywords is a compatible process. !discussion (See proposal.) !example (See proposal.) !corrigendum 02.09(2) @drepl The following are the @i (ignoring upper/lower case distinctions): @dby The following are the @i (ignoring upper/lower case distinctions): !corrigendum 02.09(3) @drepl NOTES@hr 6 The reserved words appear in @b in this International Standard, except when used in the @fa of an attribute (see 4.1.4). Lower case boldface is also used for a reserved word in a @fa used as an @fa. This is merely a convention @emdash programs may be written in whatever typeface is desired and available. @dby Keywords are categorized into @i and @i. are the nonreserved keywords. All other keywords are reserved. Reserved keywords are also referred to as @i in other parts of this International Standard. NOTES@hr 6 Nonreserved keywords can be used as identifiers. 7 The keywords appear in @b in this International Standard, except when used in the @fa of an attribute (see 4.1.4). Lower case boldface is also used for a keyword in a @fa used as an @fa. This is merely a convention @emdash programs may be written in whatever typeface is desired and available. !ACATS test !appendix From: Randy Brukardt Sent: Tuesday, December 17, 2002 2:14 PM Pascal didn't mention that AI-284 (unreserved keywords) also was rejected by WG9. Here is a summary as to why: "In the case of 284, many members of WG9 expressed reservations regarding where the concept of non-reserved keywords might lead. Several of them mentioned that making new reserved keywords is not such a bad thing. The overall consensus is that WG9 would like a more complete list of keywords proposed for non-reserved status before making a decision on the subject of whether a non-reserved status should be permitted." I believe that the primary driver for this is to allow "interface" as a keyword; making it reserved is not possible, because of pragma Interface in Ada 83. So that seems to imply that whether or not we resubmit this AI will depend completely on the fate of the interfaces proposal. (The only other AI currently using unreserved keywords is alternative #2 of AI-218. We could revert to alternative #1 without much pain - WG9 has already approved that anyway). I don't think there is anything that we need to (or can) do about this currently, but I thought it was important that everyone know about this rejection. ************************************************************* From: Robert A. Duff Sent: Tuesday, December 17, 2002 2:53 PM This is the sort of thing that makes me think Ada *deserves* its bad reputation as a "design by committee" language. Sigh. Some folks don't like non-reserved keywords because of the above FUD (i.e., "reservations regarding where the concept ... might lead"). Other folks would rather die than admit new reserved words into the language (I know -- I was a member of the MRT, which got regularly tarred and feathered for suggesting new reserved words). And because of the way democracy works, these two factions together can successfully kill the single most important language extension in Ada 0Y (interfaces). > I believe that the primary driver for this is to allow "interface" as a > keyword; That was the most pressing example. But the more general idea is to allow us to evaluate proposals on their merits, rather than endlessly arguing about this silly reserved words issue. >... making it reserved is not possible, because of pragma Interface in > Ada 83. I wouldn't say "not possible". Surely we could deal with a pragma whose name is a reserved word. It's a minor annoyance for compilers. I think the real reason is that there are probably lots of programs out there that use "interface" as an identifier, and we don't want to break them. ************************************************************* From: Jean-Pierre Rosen Sent: Wednesday, December 18, 2002 1:52 AM 1) Have you any data to support this statement ? I personnaly have quite oftten things called OS_Interface, Hardware_Interface, Blah_Interface... But Interface alone ? Never, it would be a terrible non-informative identifier. 2) Changing an identifier is not a big issue. You can freely use Adasubst from Adalog's Web site ;-) 3) At AFNOR, we discussed that issue with a very serious guy from Thales (making reusable software for all the Thales radars product line). His position was that as long his systems were not changing platform, OS, etc he would keep the same (Ada95) compiler. So moving to an Ada05 compiler would happen only when changing the target computer, and that in this case changing a couple of identifiers was really peanuts compared to what had to be adjusted anyway. So he considered adding new keywords as not problematic. ************************************************************* From: Pascal Leroy Sent: Wednesday, December 18, 2002 4:19 AM > > I believe that the primary driver for this is to allow "interface" as a > > keyword; > > That was the most pressing example. But the more general idea is to > allow us to evaluate proposals on their merits, rather than endlessly > arguing about this silly reserved words issue. Agreed, and I am going to ignore the fact that WG9 sent 284 back to the ARG. I want to discuss syntax as if we could freely add reserved/non-reserved words. So for instance I am going to leave the word "interface" in the syntax for 251. At some point in time we will go to WG9 and ask them to decide whether they want to (1) add new reserved words, (2) add unreserved words or (3) conjure up some unreadable combination of existing reserved words. Because this is mostly a political issue (there is really no technical content to that issue) the HoDs will have to face their responsibilities. ************************************************************* From: Pascal Leroy Sent: Wednesday, December 18, 2002 4:51 AM > 1) Have you any data to support this statement ? I personally > have quite often things called OS_Interface, Hardware_Interface, > Blah_Interface... But Interface alone ? Never, it would be a > terrible non-informative identifier. I know of people who name all of their types Object, why not Interface? > 3) At AFNOR, we discussed that issue with a very serious guy > from Thales (making reusable software for all the Thales > radars product > line). His position was that as long his systems were not > changing platform, OS, etc he would keep the same (Ada95) compiler. So > moving to an Ada05 compiler would happen only when changing > the target computer, and that in this case changing a couple of > identifiers was really peanuts compared to what had to be > adjusted anyway. So he considered adding new keywords > as not problematic. Ok, so we have a statistical sample of one person saying that he doesn't care if we add reserved words. Fine. What about the thousands of other users who might/do care? I agree that changing identifiers can be automated. But what about the other artifacts of real projects that may also contain type names? Documentation, design models, requirement traceability matrices, etc. You would presumably need to change those too, and that's not going to be as easy to automate. What about programs that generate Ada code and contain identifiers as part of string literals? What about comments? New reserved words are a highly visible change, and we should be really cautious here, lest users start viewing the 05 revision as jettisoning compatibility. ************************************************************* From: Jean-Pierre Rosen Sent: Wednesday, December 18, 2002 8:21 AM > Ok, so we have a statistical sample of one person saying that he doesn't > care if we add reserved words. Fine. What about the thousands of other > users who might/do care? The problem I have is that I keep hearing vendors claiming that users would not accept the slightest incompatibility, but I have yet to meet a user that says directly the same thing. Maybe it is just that these people do not shout strong enough, but I have currently no evidence of that (and I have some of the other way round). > I agree that changing identifiers can be > automated. But what about the other artifacts of real projects that may > also contain type names? Documentation, design models, requirement > traceability matrices, etc. You would presumably need to change those too, > and that's not going to be as easy to automate. What about programs that > generate Ada code and contain identifiers as part of string literals? What > about comments? Good points. >New reserved words are a highly visible change, and we > should be really cautious here, lest users start viewing the 05 revision as > jettisoning compatibility. We have the experience of Ada95. 6 keywords were added, but I don't think this has been a major cause of trouble. ************************************************************* From: Pascal Leroy Sent: Wednesday, December 18, 2002 8:45 AM > We have the experience of Ada95. 6 keywords were added, but I don't think > this has been a major cause of trouble. I remember one particular customer who had implemented in Ada 83 a poor man's form of delay relative statement: function Until (T : Calendar.Time) return Duration; delay Until (Some_Time); The funny thing is that when going to Ada 95 they didn't have to change their delay statements, they only had to delete all the functions named Until. I guess they were lucky... Remember that some of the 6 new keywords in Ada 95 were quite unlikely to be used in identifiers: nobody with half a brain would use a variable named Tagged ;-) ************************************************************* From: Jean-Pierre Rosen Sent: Wednesday, December 18, 2002 8:58 AM IIRC, there was some statistical analysis of the proposed new reserved words in existing programs. I think only "protected" appeared every now and then. I might be useful to do the same for Interface, to know if there *is* a problem in the first place. ************************************************************* From: Robert A. Duff Sent: Wednesday, December 18, 2002 9:00 AM > > I think the real reason is that there are probably lots of programs out > > there that use "interface" as an identifier, and we don't want to break > > them. > > > 1) Have you any data to support this statement ? No. In "science", one uses statistically significant data. But this is "computer science", where we reason from vague anecdotes and personal opinion. ;-) > ...I personnaly have quite oftten things called OS_Interface, > Hardware_Interface, Blah_Interface... But Interface alone ? Never, it > would be a terrible non-informative identifier. Well, there's one called "Interfaces" in the RM... > 2) Changing an identifier is not a big issue. You can freely use > Adasubst from Adalog's Web site ;-) I would be happy to have the interfaces proposal, whether "interface" is a reserved word or an unreserved word. (I prefer the latter, since it's slightly less disruptive, but I agree with you that it's not a big deal.) The problem is that there are people who think it *is* a big deal. So if you think the interfaces proposal is a good idea, and you think unreserved keywords is a *bad* idea, you should vote *for* unreserved keywords, because otherwise you will kill the interfaces proposal (by forcing it to use a new reserved word, or forcing it to use an unreadable combination of existing reserved words (or pragmas!)). This is how a "democratic" committee like WG9 works, and people should be aware that it is sometimes unwise to vote for what you think is best. That's not dishonest -- it's just a recognition that one cannot get exactly what one wants. > 3) At AFNOR, we discussed that issue with a very serious guy from > Thales (making reusable software for all the Thales radars product > line). His position was that as long his systems were not changing > platform, OS, etc he would keep the same (Ada95) compiler. So moving > to an Ada05 compiler would happen only when changing the target > computer, and that in this case changing a couple of identifiers was > really peanuts compared to what had to be adjusted anyway. So he > considered adding new keywords as not problematic. You mean, he would keep the same *version* of the same Ada95 compiler? We (SofCheck) have customers like that -- who don't want *any* compiler changes, or perhaps only compiler changes they have specifically asked for -- no general improvements or bug fixes they don't need. That makes sense in certain environments. I suspect that Ada05 compilers will be new versions of Ada95 compilers -- not totally new compilers. So moving to Ada05 will not be much different from moving to a new version of the same Ada95 compiler. ************************************************************* From: Pascal Leroy Sent: Wednesday, December 18, 2002 9:11 AM > I might be useful to do the same for Interface, to know if there *is* a problem in the first place. Just looking at some piece of technology from one of our competitor, I found a package named Gnatcom.Interface. David Botton and the ACT folks should be severely punished for using such "a terrible non-informative identifier." ;-) The word Interface is perfectly appropriate here, because this package models, well, a COM interface. I suppose that renaming the package could impact quite a few people out there. ************************************************************* From: Robert A. Duff Sent: Wednesday, December 18, 2002 9:40 AM > We have the experience of Ada95. 6 keywords were added, but I don't think > this has been a major cause of trouble. I agree. The main cause of trouble when switching compilers (or compiler versions) is compiler bugs. Even when the new compiler supports a new version of the language. But I'm encouraging you to view this as primarily a political issue, not a technical one. ************************************************************* From: Robert A. Duff Sent: Wednesday, December 18, 2002 9:43 AM > IIRC, there was some statistical analysis of the proposed new reserved > words in existing programs. I think only "protected" appeared every > now and then. I might be useful to do the same for Interface, to know > if there *is* a problem in the first place. Feel free to do so, but I really think it's a waste of time, since we have a good technical solution that is guaranteed to cause *no* problems with new reserved words -- namely, the unreserved keyword solution. ************************************************************* From: Robert Dewar Sent: Wednesday, December 18, 2002 10:19 AM > Remember that some of the 6 new keywords in Ada 95 were quite unlikely to be > used in identifiers: nobody with half a brain would use a variable named > Tagged ;-) Actually that's a pretty natural adjective to use in a program for a function returning a Boolean for instance if Tagged (case1) then ... And I did see a couple of programs with this usage ************************************************************* From: Robert Dewar Sent: Wednesday, December 18, 2002 10:30 AM > I agree. The main cause of trouble when switching compilers (or > compiler versions) is compiler bugs. Even when the new compiler > supports a new version of the language. Actually that is not our experience at all, the major cause of portability troubles has been implementation dependent usage, particularly in the area of representation clauses. Yes, we sometimes run into compiler bugs, but these are always quick to work around or fix, but heavy dependence on implementation dependent features in some cases requires major changes in customer code, and that is far harder to deal with. I agree that a new reserved word is not a big deal, although the choice of interface is really quite nasty, since as already pointed out we make significant use of this identifier now. ************************************************************* From: Robert Dewar Sent: Wednesday, December 18, 2002 10:31 AM > Feel free to do so, but I really think it's a waste of time, since we > have a good technical solution that is guaranteed to cause *no* problems > with new reserved words -- namely, the unreserved keyword solution. Three cheers for PL/1 :-) I agree, why buy trouble? ************************************************************* From: Jean-Pierre Rosen Sent: Wednesday, December 18, 2002 10:32 AM > You mean, he would keep the same *version* of the same Ada95 compiler? > We (SofCheck) have customers like that -- who don't want *any* compiler > changes, or perhaps only compiler changes they have specifically asked > for -- no general improvements or bug fixes they don't need. That makes > sense in certain environments. Yes. When a project is baselined with a compiler, they simply don't want to change it. ************************************************************* From: Jean-Pierre Rosen Sent: Wednesday, December 18, 2002 11:03 AM > I agree that a new reserved word is not a big deal, although the choice > of interface is really quite nasty, since as already pointed out we > make significant use of this identifier now. > Reading all this discussion, it seems that it would be much easier if the new keyword was not "interface". Why not: type T is abstract interfacing; or even (only half joking): type T is for interfacing; (bring more, suggesting syntax is such a fun) *************************************************************