CVS difference for ais/ai-10284.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-10284.txt

--- ais/ai-10284.txt	2004/07/23 02:26:50	1.1
+++ ais/ai-10284.txt	2004/09/04 01:13:47	1.2
@@ -177,4 +177,506 @@
 
 !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