Version 1.10 of ais/ai-00284.txt

Unformatted version of ais/ai-00284.txt version 1.10
Other versions for file ais/ai-00284.txt

!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)
Replace the paragraph:
The following are the reserved words (ignoring upper/lower case distinctions):
by:
The following are the keywords (ignoring upper/lower case distinctions):
!corrigendum 02.09(3)
Replace the paragraph:
NOTES
6 The reserved words appear in lower case boldface in this International Standard, except when used in the designator of an attribute (see 4.1.4). Lower case boldface is also used for a reserved word in a string_literal used as an operator_symbol. This is merely a convention — programs may be written in whatever typeface is desired and available.
by:
Keywords are categorized into reserved keywords and nonreserved keywords. <Empty> are the nonreserved keywords. All other keywords are reserved.
Reserved keywords are also referred to as reserved words in other parts of this International Standard.
NOTES
6 Nonreserved keywords can be used as identifiers.
7 The keywords appear in lower case boldface in this International Standard, except when used in the designator of an attribute (see 4.1.4). Lower case boldface is also used for a keyword in a string_literal used as an operator_symbol. This is merely a convention — 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)

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

From: Robert A. Duff
Sent: Monday, September 29, 2003  5:43 AM

[Editor's note: This discussion started on AI-251 syntax; see that AI for
the note quoted.]

> This doesn't make sense at all.  The sole purpose of unreserved keywords
> is to avoid incompatibilities.  As you know, unreserved keywords are
> already a contentious issue.  Unreserved keywords with incompatibilities
> are sure to be shot down at the WG9 level.  For my part, I am going to
> oppose any AI that has such a blatant incompatibility anyway.

The potential confusion between "Interface is" and "interface Mumble is"
is no big deal, in my opinion.  If you get it wrong, you get a
compile-time error message, which is relatively harmless.

Useful compiler options would be to warn about uses of unreserved
keywords as identifiers, or to treat them as reserved words.
Let's leave that sort of thing to compiler options.

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

From: Robert Dewar
Sent: Monday, September 29, 2003  9:16 AM

> Useful compiler options would be to warn about uses of unreserved
> keywords as identifiers, or to treat them as reserved words.
> Let's leave that sort of thing to compiler options.

I must say i dislike the whole business of unreserved keywords. It's quite
a pain to handle nicely (for instance this means that in error messages
you have to be careful to understand whether interface is a keyword or
an identifier).

> If you get it wrong, you get a
> compile-time error message, which is relatively harmless.

Right, it your attitude is simply, ok you get an error message, no big deal,
then fair enough, but if you are in the business of trying to provide really
accurate helpful messages, this near ambiguity is indeed painful.

It seems to me that if Ada0Y becomes a reality, and if it is used in treal
projects, then any such project would have coding guidelines forbidding
the use of these unreserved keywords as identifiers, and any decent compiler
would have a mode (probably the default mode) to prohibit any such use.

So that means that in practice, legacy code will have to be fixed to remove
identifier use of these keywords anyway, so the idea that you are helping
compatibility significantly by introducing this nasty new concept is bogus.

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

From: Jean-Pierre Rosen
Sent: Monday, September 29, 2003  10:42 AM

> Useful compiler options would be to warn about uses of unreserved
> keywords as identifiers, or to treat them as reserved words.
> Let's leave that sort of thing to compiler options.

There is a very interesting idea here, that might make the idea of unreserved
keywords more acceptable. Explicitely mention (implementation permission?) that
a compiler may have a mode where the keywords are actually reserved. In
practice, there should be no test to check that they are really "unreserved".

It may turn out that the "normal" mode of a compiler would be to have them
reserved, and a "legacy" mode for older programs accepting the keywords as
identifiers.

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

From: Robert A. Duff
Sent: Monday, September 29, 2003  1:54 PM

I wrote:

> > Useful compiler options would be to warn about uses of unreserved
> > keywords as identifiers, or to treat them as reserved words.
> > Let's leave that sort of thing to compiler options.

JPR replied:

> There is a very interesting idea here, that might make the idea of
> unreserved keywords more acceptable. Explicitely mention
> (implementation permission?) that a compiler may have a mode where the
> keywords are actually reserved.

Sounds good..

>... In practice, there should be no test
> to check that they are really "unreserved".

But I object to this kind of legislation by the courts or the police or
whatever.  I believe that Ada should be a language where "interface" is
allowed as a user-defined identifier, or not allowed as a user-defined
identifier.  I see no point in allowing vendors to make that choice.
After all, the whole point of "unreserved keywords" is to ensure
portability (among versions of the language, and therefore among
compiler versions).

> It may turn out that the "normal" mode of a compiler would be to have
> them reserved, and a "legacy" mode for older programs accepting the
> keywords as identifiers.

Compilers can do what they like in "normal" mode, but they must have a
"standard" mode.  It would be nice of those were the same mode, but we
cannot and should not legislate that.  If they call "standard" mode
"legacy" mode, that's fine, but I don't want to make that mode optional,
either in the Standard, or in the test suite.

If we do go with "unreserved keywords" (which I think is probably a good
idea), I suggest the test suite add explicit tests that these words are
indeed unreserved.

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

From: Robert I. Eachus
Sent: Monday, September 29, 2003  6:43 PM

> So that means that in practice, legacy code will have to be fixed to remove
> identifier use of these keywords anyway, so the idea that you are helping
> compatibility significantly by introducing this nasty new concept is bogus.

I strongly agree.  Adding two unreserved keywords* would complicate the
language a lot, and as Robert Dewar says, any reasonable project migrating from
Ada95 to Ada0Y will insure those words are only used as keywords anyway.  So it
makes lots of work for compiler people, extra work when teaching Ada for the
indefinite future, and to save what?  An hour or two of additional work on some
projects that decide to move their code base forward to Ada 0Y.

Ada 95 added six new reserved words.  I don't remember anyone ever complaining
about the "extra" work to revise code caused by this.  I think we should bite
the bullet now and decide that there will be new reserved words again.

*As far as I know, the two "unreserved" keywords being considered are INTERFACE
and OVERRIDES.  Are there any others?  (I can't imagine using overrides as an
identifier, and I personally tend to use interface as the second half of a
package name: Radar_Interface or some such.

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

From: Randy Brukardt
Sent: Monday, September 29, 2003  6:55 PM

The problem, of course, is the Ada 83 pragma Interface. While that is no
longer in the standard, we don't want to make it illegal for implementations
to support such a pragma.

I suppose that could be fixed by defining it to be obsolecent (then using
the reserved word for a name would be allowed), but it seems like a messy
fix.

(I don't know if I care much either way on this one.)

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

From: Tucker Taft
Sent: Monday, September 29, 2003  7:00 PM

"Interface" is the real issue.  I believe there
is a child package named GNAT.<whatever>.Interface in
the GNAT library, as an example of a typical
conflict.

But I agree reserved word incompatibilities are of
the least nasty kind.  You deal with it, and get
past it quickly.  It is more of a psychological
barrier.  When someone first introduced the idea
of using "interface" rather than "abstract" for
abstract interface types, there was general horror
at the obvious incompatibility.  But after a while,
as people integrate the idea of "interace" types into
there model of "future Ada," worrying about existing
uses of the identifier "interface" lessens, and we are
more willing to accept a new reserved word.

So as long as the interface type proposal doesn't get
shot down because of the use of a new reserved word,
I certainly don't have any compelling desire to introduce
the complexity of non-reserved keywords.  *But*, if the
incompatilibity concerns suddenly blossom again, then
I'm all for using the appropriate word in the syntax
and living with the non-reserved keyword approach.

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

From: Robert Dewar
Sent: Monday, September 29, 2003  7:53 PM

> It may turn out that the "normal" mode of a compiler would be to have them
> reserved, and a "legacy" mode for older programs accepting the keywords as
> identifiers.

So what's wrong with a legacy mode called -Ada95
That seems perfectly adequate to me for legacy code.

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

From: Robert Dewar
Sent: Monday, September 29, 2003  8:35 PM

That's exactly right, you can't have it both ways. If you introduce the
abomination of unreserved keywords (which I thought had been permanently
put out of business by PL1) then you have to accept the consequences and
make sure that all compilers waste time and effort supporting this
(nasty) feature.

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

From: Robert Dewar
Sent: Monday, September 29, 2003  9:23 PM

> The problem, of course, is the Ada 83 pragma Interface. While that is no
> longer in the standard, we don't want to make it illegal for implementations
> to support such a pragma.

Just allow implementations to support pragmas whose names are reserved.
I don't see a problem, we allow this for attributes. This would be no
implementation difficulty as far as I can see, and is only there for
implementations that want to fiddle with interface.

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

From: Robert Dewar
Sent: Monday, September 29, 2003  9:28 PM

> I believe there
> is a child package named GNAT.<whatever>.Interface in
> the GNAT library, as an example of a typical conflict.

Well if that is a typical example, worry less, since it does not exist :-)

> So as long as the interface type proposal doesn't get
> shot down because of the use of a new reserved word,
> I certainly don't have any compelling desire to introduce
> the complexity of non-reserved keywords.  *But*, if the
> incompatilibity concerns suddenly blossom again, then
> I'm all for using the appropriate word in the syntax
> and living with the non-reserved keyword approach.

I have exactly the opposite viewpoint. I am quite OK with the interface
type proposal, IF AND ONLY IF interface is a new keyword, otherwise I
would prefer to look for alternatives.

I find this business of "we really want new keyword xxx, but we don't
want more reserved keywords, so we will make it unreserved" extremely
ugly. Since the idea of nice syntactical ideas is to improve the syntax
of the language, such approaches always fail for me, because the damage
done by the introduction of this weird non-orthogonal feature is too
serious.

I would rather have NOT WITH IN OUT ENTRY or some such drivel than
non-reserved keywords :-)

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

From: Arnaud Charlet
Sent: Tuesday, September 30, 2003  1:58 AM

> "Interface" is the real issue.  I believe there
> is a child package named GNAT.<whatever>.Interface in
> the GNAT library, as an example of a typical
> conflict.

As Robert said, there's no such example.
I believe the only example given during past discussion was
GNATCOM.Interface or some such. But then, I'm sure David would have
no trouble renaming it to something else (e.g. GNATCOM.Interfaces)
for the next version of GNATCOM. Generally speaking, any example of
the use of 'Interface' in free software should not be considered as a
showstopper, since free software typically evolves rapidly and can be
modified by anyone freely.

I also do not like the idea of unreserved keywords, and would rather
introduce a couple new keywords in the language.

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

From: John Barnes
Sent: Tuesday, September 30, 2003  2:07 AM

>> *As far as I know, the two "unreserved" keywords being considered
>> are INTERFACE and OVERRIDES.  Are there any others?
[attribution lost]

It's OVERRIDING actually.

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

From: Pascal Leroy
Sent: Tuesday, September 30, 2003  3:39 AM

> > I believe there
> > is a child package named GNAT.<whatever>.Interface in
> > the GNAT library, as an example of a typical
> > conflict.
>
> Well if that is a typical example, worry less, since it does
> not exist :-)

I think Tuck was referring to GNATCOM.Interface.  Last time I checked,
this did exist.  It is pretty hard to do anything useful on Windows
without GNATCOM, and it's pretty hard to do anything with COM without
interfaces, so I would guess that there would be quite a few users of
that package.  Forcing then to update their code just because someone
didn't like unreserved keywords would be irresponsible in my opinion.
Surely we are talking about a much larger impact than, say, the
introduction of "aliased" or "tagged".

On the other hand, I suppose that I should not worry too much about a
language change that would make life difficult _only_ for users of GNAT.
:->

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

From: Robert Dewar
Sent: Tuesday, September 30, 2003  4:25 PM

Well this is an Ada Core product, and so I think our opinion should count
for something.

> On the other hand, I suppose that I should not worry too much about a
> language change that would make life difficult _only_ for users of GNAT.

If we don't consider it a problem, I hardly think that Pascal has a strong
argument in this particular case :-)

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

From: Robert Dewar
Sent: Tuesday, September 30, 2003  4:27 PM

In general let me say that here at Ada Core, we are of course reluctant
to introduce non-compatible changes. But we will do so if

a) it really is a cleanup
b) the effort of change is small

An example is our restriction identifier No_Tasking, introduced because
the RM would not allow us to diagnose Max_Tasks => 0 at compile time.
But the ARG fixed this (thank you) and now we will get rid of No_Tasking,
even though this means that some users will have to change their code
to use the (now) standard form Max_Tasks => 0.

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

From: Jean-Pierre Rosen
Sent: Tuesday, September 30, 2003  2:33 AM

Bob Duff said:
...
> If we do go with "unreserved keywords" (which I think is probably a good
> idea), I suggest the test suite add explicit tests that these words are
> indeed unreserved.

I guess the difference between you and me is that I do not like "unreserved"
keywords. I've been teaching for years that Ada is a carefully designed piece
of work, and this looks like an ugly kludge with no other reason than
compatibility. I am really concerned that people from other languages will
lough at us on this.

Now, if you tell me that these words *are* reserved, but the compiler is
allowed to have a mode where they are still accepted for compatibility (but not
necessarily an Ada95-only mode), I could buy that.

In non-standard mode, a compiler can do 100% what it pleases (including
compiling FORTRAN). I really don't want to prevent validation of a compiler
that would treat all keywords as reserved words.

As far as portability is concerned, a program that would use these keywords as
identifiers would not be portable, full stop.

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

From: Robert I. Eachus
Sent: Tuesday, September 30, 2003  11:19 AM


Randy wrote:

> The problem, of course, is the Ada 83 pragma Interface. While that is no
> longer in the standard, we don't want to make it illegal for implementations
> to support such a pragma.
>
> I suppose that could be fixed by defining it to be obsolecent (then using
> the reserved word for a name would be allowed), but it seems like a messy
> fix.

If it isn't in Annex J currently (or anywhere else in the ARM) why add it back
in?  Yes compilers could support an Ada 83 mode, or even allow this in an Ada
95 mode.  But otherwise I think it comes under the same heading as user defined
names.  If someone wants to use the Ada 0Y features they have to change all
occurances of pragma Interface to pragma Import, if they haven't already.

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

From: Randy Brukardt
Sent: Tuesday, September 30, 2003  5:29 PM

Because an implementation-defined pragma cannot be named with a reserved
word. (Yes, we could change that, as Robert Dewar suggests). But I don't
think the incompatibility of disallowing Interface (a commonly used pragma
in older code) is going to fly.

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

From: Robert Dewar
Sent: Tuesday, September 30, 2003 10:15 PM

So you can always allow it in non-standard mode :-)

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


Questions? Ask the ACAA Technical Agent