Version 1.5 of ais/ai-10284.txt

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

!standard 2.09 (02)          04-11-09 AI95-00284-02/03
!standard J.12 (01)
!class amendment 04-07-19
!status Amendment 200Y 04-09-22
!status ARG Approved 9-0-0 04-09-17
!status work item 04-07-19
!status received 04-07-19
!priority Medium
!difficulty Medium
!subject New reserved words
!summary
"interface", "overriding", and "synchronized" are reserved words.
!problem
Three new keywords need to 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.
!proposal
(See summary.)
!wording
Add "interface", "overriding", and "synchronized" to the list of reserved words in 2.9(2).
Add a new clause to Annex J:
J.12 Pragma Interface
Syntax
In addition to an identifier, the reserved word "interface" is allowed as a pragma name, to provide compatibility with a prior edition of this International Standard.
AARM Note
All implementations need to at least recognize and ignore this pragma. A syntax error is not an acceptable implementation of this pragma.
!discussion
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 use 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, it is added to Annex J.
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 a root package, because of the possible confusion with the package Interfaces. It is possible that the name might 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.
-----
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 a one-shot modification to existing programs, while having them nonreserved 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.
!example
(See discussion.)
!corrigendum 02.09(2)
Add to the list:
interface

overriding
synchronized
!corrigendum J.12(1)
Insert new clause:
Syntax
In addition to an identifier, the reserved word interface is allowed as a pragma name, to provide compatibility with a prior edition of this International Standard.
!ACATS test
!appendix

From: Dirk Craeynest
Sent: Sunday, August 29, 2004  3:33 PM

Further to the arguments in AI95-00284-02, the "New reserved words"
alternative for AI95-00284-01 (which introduced non-reserved keywords),
here are some additional data points given by various people working on
large industrial Ada projects in Belgium.  All these projects have
operational systems and work on new developments.

Organization with +- 500K lines of code:

"We have a strong preference for adding the 3 keywords as new reserved
words.  A simple and consistent language definition is valued much
higher than the slight porting inconvenience that new keywords may
introduce.
New keywords have been added in the 9X project, and in all reports of
porting experiences this has been described as a non-problem, so why
should it be done differently now?  In the Ada83-95 port of our system,
the fixes for new keywords were trivial; a check for the 3 new Ada05
keywords showed that they do not even appear in the source code as
identifiers at all."

Organization with unknown volume of code:

"For what it's worth, I agree with the AFNOR's proposal.  I wouldn't
want to have to explain what [non-reserved keywords] are to a beginner,
and as a practitioner, I wouldn't want any surprises such as in the
example in the AFNOR's proposal.  I don't really have anything to add
to the AFNOR's proposal; I think it is just fine."

Organization with > 1.2M lines of code:

[One person:]
"Based on our experience [] porting from Ada83 to Ada95, we largely
prefer having a simpler and consistent language than having a new
concept cluttering the language.  It is straightforward to modify a
new reserved keyword in something not reserved when porting from one
to another, so ..."

[2nd person:]
"We have 209 lines to modify for a keyword 'Interface' [and none for
the other keywords].  As far as I can see replacing by 'Interfaces'
would work in all cases.  My personal preference is AFNOR. Just
introduce the new keyword, and do not invent half-baked non-reserved
keywords. The porting cost isn't significantly influenced by such
trivial substitutions."

[3rd person:]
"[...] I agree [with the AFNOR proposal].  I didn't quite finish
digesting the full debate but I read both proposals and I favor that
Ada05 is simple and consistent at the potential cost to those porting
from Ada95."

This user feedback is offered in the hope that it might be useful.

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

From: Randy Brukardt
Sent: Monday, August 30, 2004  11:07 PM

Now that WG9 has voted clearly in favor of new reserved words, I wanted to
voice my discomfort with Jean-Pierre's proposal (lest it get lost).

The proposal changes the syntax of pragmas to allow the reserved word
"interface" to be used as a pragma name -- and *only* the reserved word
"interface". There is absolutely no use of this syntax elsewhere in the
Standard, so it is totally mysterious. Indeed, it almost looks like a
mistake. There needs to be some indication of why this is, and (most
importantly) why "interface" rates this treatment, and other reserved words
(both new and old) don't. Even with an AARM note, this will be mysterious to
readers of the Standard (rather than the AARM).

My preference for solving this problem would simply have been an
implementation permission:
    Implementations may use reserved words as implementation-defined pragma
names.
(Or, just limit it to new reserved words.) That would make it far less
obvious than a syntax change does. We "hide" the syntax for the obsolescent
features in Annex J, and certainly pragma Interface is in this category.
Indeed, we could even put this in Annex J, because that's why it exists.

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

From: Robert Dewar
Sent: Tuesday, August 31, 2004  8:30 PM

> Now that WG9 has voted clearly in favor of new reserved words, I wanted to
> voice my discomfort with Jean-Pierre's proposal (lest it get lost).

I agree it's odd. Why not just put pragma Interface into the language and
be done with it. If we are going this far to allow compilers to do it, and
in fact all compilers *do* do it, why not say so. This would make things
far less mysterious.

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

From: Jean-Pierre Rosen
Sent: Wednesday, September 1, 2004  1:52 AM

The vote was between "reserved" and "unreserved" words. For reserved
words to be acceptable, I had to provide a solution to the pragma
Interface problem, and what I suggested is simply copied from
attributes: that's how 'delta is allowed in  the language.

If you have a better solution, I don't think there is a problem in
proposing an improvement to AI-10284. But the current syntax defines a
pragma name as an identifier, and a keyword is not an identifier.
Therefore, you would need:
    pragma ::= pragma pragma_designator [(pragma_argument_association
                                  {, pragma_argument_association})];
    pragma_designator ::= identifier | keyword

And of course, to be consistent, you need to do the same thing to
attributes. Is it worth it? I have no opinion on this.

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

From: John Barnes
Sent: Wednesday, September 1, 2004  2:02 AM

From: "Randy Brukardt" <randy@rrsoftware.com>

> My preference for solving this problem would simply have been an
> implementation permission:
>     Implementations may use reserved words as implementation-defined
pragma
> names.

> (Or, just limit it to new reserved words.) That would make it far less
> obvious than a syntax change does. We "hide" the syntax for the
obsolescent
> features in Annex J, and certainly pragma Interface is in this category.
> Indeed, we could even put this in Annex J, because that's why it exists.

I agree, just put an implementation permission in annex J and get rid of the
nasty syntax in the AI.

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

From: Pascal Leroy
Sent: Wednesday, September 1, 2004  3:35 AM

I agree that this is the best approach.

I don't want to spend any time incorporating pragma Interface in the
language because to do that we would have to nail down its semantics.  But
its semantics was awfully muddled in Ada 83, and I am sure that all
implementations differ to some extent.  So either we would have to have
plenty of implementation-defined behavior, or we would create
incompatibilities with existing compilers.  Neither is appealing.

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

From: Robert Dewar
Sent: Wednesday, September 1, 2004  4:25 AM

I disagree. A fundamental property of pragmas is that if a compiler
does not recognize a pragma, it still parses it properly and ignores
it. You threaten to break this, unless you intend that all compilers
must recognize all possible keywords following pragma, which is
a real pain.

The pragma Interface is a special case. I cannot imagine that all
Ada 95 compilers do not implement this pragma, and the appropriate
implementation is quite simple

    pragma Interface (convention_name, entity_name);

should simply be identical to

    pragma Import (convention_name, entity_Name);
>
> I don't want to spend any time incorporating pragma Interface in the
> language because to do that we would have to nail down its semantics.  But
> its semantics was awfully muddled in Ada 83, and I am sure that all
> implementations differ to some extent.  So either we would have to have
> plenty of implementation-defined behavior, or we would create
> incompatibilities with existing compilers.  Neither is appealing.

I really don't think pragma Interface is that complex, and I don't
see its semantics as muddled in Ada 83. Can you be more explicit.
I don't want to avoid this obvious solution (add pragma Interface
to annex J) based on unsubstantiated claims that implementations
differ too much here. Let's substantiate first!

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

From: Robert Dewar
Sent: Wednesday, September 1, 2004  5:45 AM

One point here is that it was entirely intended that Ada 95 compilers
would provide all the pragmas and attributes of Ada 83. We did not need
to say this specifically because it is always allowable to add pragmas
and attributes.

But it is essential that the facility for doing this not be compromised,
and in particular, we should require ALL implementations to at least
recognize pragma Interface (though I must admit recognizing and
ignoring pragma Interface is not very helpful).

Can we first find out what all existing compilers do with pragma
Interface, before we decide on an appropriate action here. otherwise
we are operating without proper information.

GNAT simply treats it as equivalent to pragma Import, except that
it only allows two arguments.

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

From: Tucker Taft
Sent: Wednesday, September 1, 2004  8:06 AM

I think Robert makes a good point.  We want to be able
to ignore unrecognized pragmas.  I think we should allow
certain reserved words as pragma names, not all of them,
but we can do this with a syntax rule given in English
rather than creating BNF.  I would suggest allowing
Interface, Synchronized, and Overriding, to ensure
maximum upward compatibility from Ada 95.

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

From: Robert Dewar
Sent: Wednesday, September 1, 2004  8:32 AM

and Ada 83 :-)

Sounds reassonable to me

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

From: Robert A. Duff
Sent: Wednesday, September 1, 2004  8:59 AM

Robert says,

> One point here is that it was entirely intended that Ada 95 compilers
> would provide all the pragmas and attributes of Ada 83. We did not need
> to say this specifically because it is always allowable to add pragmas
> and attributes.
>
> But it is essential that the facility for doing this not be compromised,

I agree you there.  But...

> and in particular, we should require ALL implementations to at least
> recognize pragma Interface (though I must admit recognizing and
> ignoring pragma Interface is not very helpful).

Right -- "not very helpful" indeed.  A compiler that does not support
pragma Interface *must* make the pragma legal (ignored), but *must* make
the program illegal because of the missing body?  Your point in an
earlier message, "A fundamental property of pragmas is that if a
compiler does not recognize a pragma, it still parses it properly and
ignores it." is a good thing, which we don't want to break.  But it
doesn't apply to pragma Interface, because pragma Interface is/was in
blatant violation of the Ada 83 rule about pragmas not affecting
legality.  Which it could get away with, since it was language defined.
The "do as I say and not as I do" school of language design.  ;-)

Therefore, I suggest we simply give permission in Annex J to implement a
pragma called "Interface".  No need to require all implementations to
"recognize" it.

I could also live with just adding pragma Interface to Annex J, with
semantics defined in terms of pragma Import, as you suggested.  After
all, pragma Interface is probably implemented by the same hunk of code
as Import in compilers.  Unless Pascal or somebody can come up with some
subtle difference in the semantics -- I was under the impression that
pragma Import was deliberately designed to be a superset of Interface.

This is all something of a tempest in a teapot, since as far as I know,
all compilers *do* implement pragma Interface.  So long as we don't
accidentally forbid that, all is well.

Tucker worries about Synchronized and Overriding.  Are there any
compilers that have pragmas of these names now?  If not, I see no reason
to say anything in the RM -- no reason to allow these names to be used
in the future.

If we're going to allow *some* reserved words as pragma names, I think
we should allow *all* of them, and continue to require ignoring
unrecognized pragmas.  Picking out just one, or just three, seems like a
kludge.  As they say, "This rule is there for hysterical reasons."

> You threaten to break this [recognize-but-ignore property], unless you
> intend that all compilers must recognize all possible keywords
> following pragma, which is a real pain.

It doesn't sound like a real pain to me.  I'd say it's trivial to
implement, either for one reserved word, three reserved words, or all
reserved words.  But I don't think it's necesary.

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

From: Tucker Taft
Sent: Wednesday, September 1, 2004  3:37 PM

Robert A Duff wrote:
> ...
> This is all something of a tempest in a teapot, since as far as I know,
> all compilers *do* implement pragma Interface.  So long as we don't
> accidentally forbid that, all is well.

By making Interface a reserved word, we forbid it, based on
the current BNF for "identifier" and "pragma."

We could add words to the BNF for "identifier" in 2.3, which
currently says:

    An identifier shall not be a reserved word.

To instead say:

    An identifier shall not be a reserved word, except when
    used within a pragma.


> Tucker worries about Synchronized and Overriding.  Are there any
> compilers that have pragmas of these names now? ...

I thought these might be used, perhaps to aid transition
to Ada 2005.

> ...
> It doesn't sound like a real pain to me.  I'd say it's trivial to
> implement, either for one reserved word, three reserved words, or all
> reserved words. ...

I guess I agree with Bob that supporting *all* reserved words
is probably better than just supporting a few carefully chosen ones.
It might be a bit of a pain for a tool-generated grammar, but even
then, it is usually pretty easy to have one non-terminal that
matches pretty much anything, so long as it is only used in very restricted
contexts.

> ... But I don't think it's necesary.

Something seems to be needed to permit "pragma Interface",
even if only in Annex J.

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

From: Randy Brukardt
Sent: Wednesday, September 1, 2004  4:07 PM

Bob Duff wrote:

...
> Therefore, I suggest we simply give permission in Annex J to implement a
> pragma called "Interface".  No need to require all implementations to
> "recognize" it.
>
> I could also live with just adding pragma Interface to Annex J, with
> semantics defined in terms of pragma Import, as you suggested.  After
> all, pragma Interface is probably implemented by the same hunk of code
> as Import in compilers.  Unless Pascal or somebody can come up with some
> subtle difference in the semantics -- I was under the impression that
> pragma Import was deliberately designed to be a superset of Interface.

I just checked this, and at least in Janus/Ada, most, but not all, of the
code is shared between Import and Interface. The two differences that are
obvious:
  -- Interface does not allow overloaded names; Import does (although we
reject
     them later because we don't know what to do with them);
  -- Interface allows the use of the impl-defined Interface_Name pragma to
specify
     the link name of the entity; Import does not. (The need to support this
     extra pragma is one of the reasons for not allowing overloaded names.)

I think it would be a mistake if whatever choice we make requires *any*
implementer to spend *any* time modifying their existing implementation of
pragma Interface. Given that this is a pragma that we strongly discourage in
new code, any effort spent on it is wasted.

> This is all something of a tempest in a teapot, since as far as I know,
> all compilers *do* implement pragma Interface.  So long as we don't
> accidentally forbid that, all is well.

As Tucker points out, we need to do something, because the state of the
Standard at the moment would forbid it, as the syntax of a pragma would no
longer include pragma Interface.

My preference would be a rather weakly defined pragma Interface in Annex J;
alternatively, we could just allow all reserved words as pragma names in
Annex J. But I want to avoid something completely mysterious in the core
standard (whatever we do should be in Annex J).

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

From: Pascal Leroy
Sent: Thursday, September 2, 2004  4:48 AM

Robert wrote:

> ... and the
> appropriate implementation is quite simple
>
>     pragma Interface (convention_name, entity_name);
>
> should simply be identical to
>
>     pragma Import (convention_name, entity_Name);

I trust that this is true for GNAT, but in the case Apex these two pragmas
share practically no code, other than the basic parsing and name
resolution.

When we started implementing Ada 95 we already had a few million lines of
customer code making heavy use of pragma Interface.  We were not
particularly eager to create incompatibilities for these people, so we
made very sure that we didn't change the support of pragma Interface.  For
pragma Import on the other hand, we chose to be rather zealous in our
checking of the B.1(12-21) L-compatibility rules, in order to catch
interfacing errors early.

So for Interface anything goes: you can apply a pragma Interface to a
function returning a task and whatever happens happens.  For Import on the
other hand we strictly restrict the parameter types, and for example a
function returning a task is a no-no.

I don't want to sound like RBKD, but we would probably not implement a
language change that would require us to relax the checking of pragma
Import, or to create incompatibilities in our handling of Interface.

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

From: Robert Dewar
Sent: Friday, September 3, 2004  3:07 AM

OK, that sounds reasonable, although I must say I find the notion of these
kind of restrictions on pragma Import odd.

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

From: Robert A. Duff
Sent: Thursday, September 2, 2004  7:44 AM

> Robert A Duff wrote:
> > ...
> > This is all something of a tempest in a teapot, since as far as I know,
> > all compilers *do* implement pragma Interface.  So long as we don't
> > accidentally forbid that, all is well.
>
> By making Interface a reserved word, we forbid it, based on
> the current BNF for "identifier" and "pragma."

Yes, I understand that.  The minimal change we need to make is to add a
sentence to Annex J saying something like, "An implementation may
provide an implementation-defined pragma whose name is 'Interface'."

I object to polluting the main RM with this -- better to keep it in
Annex J.

There is no *need* to go further, and allow implementations to use other
reserved words.  Nor is there any need to require implementations to
recognize-but-ignore pragma Interface -- it is impossible to ignore it.
I have no *objection* to allowing other reserved words as impl-def
pragma names, but it's a gratuitous change.  If we make that change,
*then* we need another change to require recognize-but-ignore for
reserved words.  I have no particular objection to that, either.
I just think the minimal change is best.

> > Tucker worries about Synchronized and Overriding.  Are there any
> > compilers that have pragmas of these names now? ...
>
> I thought these might be used, perhaps to aid transition
> to Ada 2005.

I don't understand that.  If these words are not *currently* used as
pragma names, how could they ease transition?  If an implementation
wants to start supporting the new features, support them using the new
syntax.

> I guess I agree with Bob that supporting *all* reserved words
> is probably better than just supporting a few carefully chosen ones.
> It might be a bit of a pain for a tool-generated grammar, but even
> then, it is usually pretty easy to have one non-terminal that
> matches pretty much anything, so long as it is only used in very restricted
> contexts.

I think you mean tool-generated parser, not tool-generated grammar --
the latter sounds like beyond-the-state-of-the-art AI!  ;-)

For a parser generator, you just write pragma_name ::= identifier |
begin_reserved_word | end_reserved_word | ... etc.  Alternatively, you
hack the lexer to do something special immediately following "pragma".

> > ... But I don't think it's necesary.
>
> Something seems to be needed to permit "pragma Interface",
> even if only in Annex J.

Right -- I didn't mean to imply otherwise.

- Bob

P.S. Aren't you just itching to implement:

    pragma Pragma;?

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

Questions? Ask the ACAA Technical Agent