CVS difference for ais/ai-00284.txt

Differences between 1.7 and version 1.8
Log of other versions for file ais/ai-00284.txt

--- ais/ai-00284.txt	2003/01/24 04:14:27	1.7
+++ ais/ai-00284.txt	2003/09/30 02:01:11	1.8
@@ -514,3 +514,211 @@
 
 *************************************************************
 
+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.
+
+*************************************************************
+

Questions? Ask the ACAA Technical Agent