CVS difference for ai12s/ai12-0092-1.txt

Differences between 1.8 and version 1.9
Log of other versions for file ai12s/ai12-0092-1.txt

--- ai12s/ai12-0092-1.txt	2015/01/28 00:11:24	1.8
+++ ai12s/ai12-0092-1.txt	2015/01/31 01:45:26	1.9
@@ -6849,9 +6849,368 @@
 Also, Robert has said all it takes is some debating tactics.
 So we should Robert to a WG9 meeting to push it through.
 
+****************************************************************
+
+From: Brad Moore
+Sent: Tuesday, January 27, 2015  9:15 PM
+
+Well, I for one have changed my view on the reserved words debate. I think
+Robert is correct in that had there been more time and effort spent to
+examine the issue and present a case to the Ada community for using unreserved
+keywords, things might have turned out differently. As I recall, this issue
+came up late in the standardization process, rather unexpectedly.
+It's not that no one had considered the possibility that the idea might not
+sit well with everyone, but I think the amount of pushback was underestimated.
+There was probably a certain amount of fear, uncertainty, and doubt about
+introducing somewhat of an anomaly to the language, that might be regretted.
+Of course, introducing incompatibility to the language is something that surely
+should be regretted, but I think at least for me, the thinking was that making
+"some" a keyword is something that could be more easily undone if it was found
+to be a problem, since it would be a relaxation of restriction. Going the other
+way by deciding to later revert a decision and make "some" a keyword, would be
+increasing a restriction, and less likely to be a possibility.
+
+As time has passed, the decision that was made does not sit as well with me as
+it did at the time.
+
+I am wondering if there is still a possibility to make "Some" an unreserved
+keyword for the corrigenda?
+
+Could an effort be made to persuade those who might still be on the fence, or
+on the other side of the fence, to jump over the fence, or at least get some
+sort of a straw poll to see how many are in favor of making such a change,
+after making a strong case for unreserved keywords?
+
+I am also curious to hear if Adacore has encountered customers complaining about
+actual cases where the use of "some" had broken someone's build. That's not
+really that important though, as it is the perception of possibility for
+incompatibilities that scares people. But I think hearing about actual cases of
+incompatibility would strengthen the argument for making "some" unreserved.
+
+One might have thought that allowing functions to have in out parameters would
+have been more likely to have had a rough go, but a strong case was made for
+the feature. I think a strong case can similarly be made for compatibility
+issues.
+
+As an aside, I also wonder if the suppressable error idea could be used to
+retroactively reduce other incompatibilities that have been introduced since
+Ada 95, to encourage those who are still afraid to make the leap from Ada 95,
+to do so.
+
+***************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, January 28, 2015  3:08 AM
+
+> We lost this one several times at the WG-9 level.  The EU has more
+> votes than the US! ;-)
+
+Watch out! There are Europeans on this list, and the US should realize that
+they don't necessarily rule the world ;-)
+
+So yes, we Europeans tend to be more sensible to overall proper design.
+Ichbiah argued that elegance was an important quality of language design and
+TBH, I think that a lot of Ada's initial elegance has been lost.
+
+Of course, practical considerations are important, but "it costs money"
+should not be the /only/ consideration. I understand that AdaCore must listen
+to its clients (I know them, they are the same as my clients), but my
+experience is that they are excessively frightened of making any change to
+their software, tend to overstimate the cost of making a change, and
+understimate the cost of NOT making a change (if they consider the latter at
+all).
+
+For the specific case of unreserved keywords:
+When I present Ada, I keep arguing that it is a piece of engineering, designed
+after sound principles. How could I say that with a misfeature that no other
+language dared to have; an ugly ad-hoc patch impossible to explain to
+newcommers.
+
+And I don't think the incompatibility introduced by a new keyword is that
+terrible; just use the nice "refactoring" feature of GPS and you are done (or
+Adalog's Adasubst).
+
+I hear some screaming "version control"! "revalidation"! If version control
+comes in the way of making changes to identifiers, then you have a huge problem
+with your system anyway. Improving identifiers is an important part of the
+quality of a system, and I do that all the time. And revalidation is a red
+herring: either you don't change your compiler version and there is no
+compatibility issue, or you use a new compiler, and you have to revalidate,
+with or without changes.
+
+In the name of practicality, we said "it's a nuisance to have to declare access
+types everywhere, a pointer is a pointer, let's have anonymous access types
+everywhere to ease the programmer's job". And we know the terrible mess that
+was introduced.
+
+In short: of course, elegance should be balanced with cost. But cost should
+not be the /only/ factor to consider, especially if other solutions can be
+found that preserve elegance.
+
+An example: I understand that some fear that "parallel" be used in programs
+and cause compatibility problems. Let's use "cobegin" and "coend" (as in
+Occam) and keep keywords reserved.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  3:22 AM
+
+> Of course, practical considerations are important, but "it costs money"
+> should not be the/only/  consideration. I understand that AdaCore must
+> listen to its clients (I know them, they are the same as my clients),
+> but my experience is that they are excessively frightened of making
+> any change to their software, tend to overstimate the cost of making a
+> change, and understimate the cost of NOT making a change (if they
+> consider the latter at all).
+
+I think you should make sure you review the entire Birmingham presentation I
+referred to. As I said earlier, I was fascinated by the fact that INTERFACE
+being made a reserved word was their biggest problem. To recap, they had
+standardized on the use of this identifier in connection with modules that were
+shared between projects. These projects were on different release schedules and
+maintenance states (from active to baselined) and it was a lot of work to
+coordinate these changes between separate projects.
+
+Like most language designers, I think you GREATLY underestimate the costs of
+dealing with gratuitous incompatibilities. And the cost MUST concern us, if
+people decide the cost of moving to new versions of Ada is too high, then the
+ARG (and WG 9) are wasting their time continuing work on the language.
+
+I had real doubts about whether Ada 2005 was a worth while enterprise based on
+
+a) no one but AdaCore implementing it in a reasonable time frame
+
+b) so few of AdaCore customers using it
+
+I think Ada 2012 bailed us out in that the contracts are so obviously valuable
+that people are willing to face the cost . Whether we can come up with something
+that useful next time round is an interesting question.
+
+I have no problem in creating incompatibilities when the argument is strong
+enough. Indeed even given that presentation, I think that the decision to make
+INTERFACE a reserved word was supportable, and the right choice. But the burden
+is high for justifying incompatibilities, and if there is a reasonable way of
+avoiding the incompatibility, it should not be dismissed on mere aesthetic
+grounds.
+
+As far as I know SOME has not proved that much of a problem, but we will see,
+it's early days for Ada 2012 transition. If we do get customers who have a real
+problem with SOME, then probably what GNAT should do is to make SOME an
+unreserved keyword by default, with a pedantic mode to make it reserved for
+those who want to. Certainly no point in doing that in GNAT in the absence of
+such customer input, so we will have to see what happens.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  3:26 AM
+
+> For the specific case of unreserved keywords:
+> When I present Ada, I keep arguing that it is a piece of engineering,
+> designed after sound principles. How could I say that with a
+> misfeature that no other language dared to have; an ugly ad-hoc patch
+> impossible to explain to newcommers.
+
+I find this rhetoric dubious. First of all the "no language dared to have" is
+nonsense. PL/1 of course comes to mind, but there are other examples.
+
+And explaining it to anyone is quite simple, it was done to maintain
+compatibility with earlier versions. Every practical person in the computer
+industry understands this principle. Yes, every now and then huge mistakes are
+made, like abandoning the start menu in windows 8, which was a major factor in
+the near-catastrophic failure of Windows 8. With Windows 10, Microsoft comes
+back to its senses and puts the start menu back where it belongs.
+
+So, yes, you can visit unwise decisions to be incompatible if you find you get
+major customer push back!
+
+Not clear to me that the SOME issue is anywhere near that level, but I can
+easily see this issue arising in future. New reserved keywords in new versions
+of a language are a huge pain. Look at the COBOL example!
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  3:29 AM
+
+> And I don't think the incompatibility introduced by a new keyword is
+> that terrible; just use the nice "refactoring" feature of GPS and you
+> are done (or Adalog's Adasubst).
+
+This is plain nonsense. It might make sense from a hobbyist point of view, but
+in the real world, things are nowhere near that simple for deployed software.
+
+Suppose for example, you are developing a new generation of your software, you
+want to make use of the latest and greatest Ada for the new pieces, but
+interfaces are in place and cannot be changed. A new keyword can easily make it
+impractical to use the new version.
+
+***************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, January 28, 2015  3:47 AM
+
+> I find this rhetoric dubious. First of all the "no language dared to
+> have" is nonsense. PL/1 of course comes to mind, but there are other
+> examples.
+
+I know languages with reserved keywords, and languages with non-reserved
+keywords. Is there any language where part of the keywords are reserved?
+
+***************************************************************
+
+From: Brad Moore
+Sent: Wednesday, January 28, 2015  8:02 AM
+
+>> I find this rhetoric dubious. First of all the "no language dared to
+>> have" is nonsense. PL/1 of course comes to mind, but there are other
+>> examples.
+> I know languages with reserved keywords, and languages with
+> non-reserved keywords. Is there any language where part of the keywords are
+> reserved?
+
+C++11 has what they call "identifiers with special meaning",
+which I've also seen described as context-sensitive keywords.
+
+eg. override, final
+
+"Context-sensitive keywords" sounds a lot better to me than "unreserved
+keywords"
+
+Maybe that would be better terminology to use, politically.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Thursday, January 29, 2015  5:46 AM
+
+After all the language is full of such context sensitive keywords now, e.g.
+Check | Disable | Ignore for assertion policy.
+
+In some GNAT pragmas, we do run into some formal ambiguities from this, e.g.
+
+     pragma Warnings (Off);
+     --  turns warnings off
+
+     pragma Warnings (static_STRING_LITERAL);
+     --  argument is interpreted as string of warning options
+
+Ah ha! Someone says, what if I write:
+
+    Off : constant String := "a.k";
+
+    pragma Warnings (Off);
+
+    AARGH! ambiguous
+
+Well we don't think this is a real problem, but just for the sake of those who
+worry about such things, we have a note in the manual that the ambiguity is
+resolved in favor of treating Off as the context dependent keyword, rather than
+a reference to the entity.
+
+***************************************************************
+
+From: Brad Moore
+Sent: Thursday, January 29, 2015  7:34 AM
+
+If we had suppressable errors then we could say at any such use of a
+context-sensitive keyword is a suppressable error.
+
+Then we also could say that "Some", "Overriding", "Interface", and
+"Synchronized" are context-sensitive keywords, and eliminate those backward
+incompatibilities from Ada 95.
+
+***************************************************************
+
+From: Brad Moore
+Sent: Thursday, January 29, 2015  8:01 AM
+
+And Standard could be considered as a context-sensitive keyword since it can be
+used in the Default_Storage_Pool pragma, as well as Check, Disable, Ignore, C,
+Fortran, Cobol, etc, since they are also used in pragmas.
+
+Why are we making such a fuss about Standard, when we apparently are OK with
+other possibilities like;
+
+Check : constant String := "Foo";
+declare
+    pragma Assertion_Policy(Check);
+begin
+    ...
+end;
+
+or
+
+C : Integer := 0;
+
+declare
+    function Strcpy (Target : out C.char_array;
+                     Source : in  C.char_array) return Interfaces.C.int;
+       with Import => True, Convention => C, External_Name => "strcpy"; begin
+    ...
+end;
+
+And if we are also worried about backwards incompatibility from Ada 83 then
+abstract, aliased, protected, requeue, tagged, and until could also be
+reclassified as context-sensitive keywords.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 30, 2015  7:14 PM
+
+...
+> I am also curious to hear if Adacore has encountered customers
+> complaining about actual cases where the use of "some" had broken
+> someone's build. That's not really that important though, as it is the
+> perception of possibility for incompatibilities that scares people.
+> But I think hearing about actual cases of incompatibility would
+> strengthen the argument for making "some" unreserved.
+
+I'm not AdaCore, but as I reported at the time, "some" is quite widely used as a
+parameter name in the code of Janus/Ada. I forget precisely why (I reported on
+it extensively at the time, so it's somewhere in the mail for AI05-0176-1). That
+apparently swayed precisely no one. Thus, it would have to have to be quite an
+amazing example to change minds at this point.
+
 ***************************************************************
 
 From: Randy Brukardt
+Sent: Friday, January 30, 2015  7:29 PM
+
+...
+> Why are we making such a fuss about Standard, when we apparently are
+> OK with other possibilities like;
+>
+> Check : constant String := "Foo";
+> declare
+>     pragma Assertion_Policy(Check);
+> begin
+>     ...
+> end;
+...
+
+In none of those other cases is any other kind of entity allowed in the pragma;
+ONLY identifiers-specific-to-the-pragma are allowed. Default_Storage_Pool is
+therefore different (someone could have sensibly meant an object named
+Standard).
+
+...
+> And if we are also worried about backwards incompatibility from Ada 83
+> then abstract, aliased, protected, requeue, tagged, and until could
+> also be reclassified as context-sensitive keywords.
+
+Parsing would become challenging (at least for table-driven parsers like ours)
+if everything turned into "identifier". It's OK in some places because there's
+no possible ambiguity, but I'd hate to parse:
+
+    subtype Aliased is Integer range 1 .. 10;
+    Obj : aliased aliased;
+
+***************************************************************
+
+From: Randy Brukardt
 Sent: Monday, January 26, 2015  4:07 PM
 
 ...
@@ -7222,6 +7581,445 @@
 
 ***************************************************************
 
+From: Robert Dewar
+Sent: Tuesday, January 27, 2015  8:03 PM
+
+Makes me think we should default in GNAT to allowing the copy case, to ease
+transition to Ada 2012, to be thought about ...
+
+***************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 27, 2015  6:48 PM
+
+> > Are you mixing up compile time and run time?
+>
+> Definitely not.
+
+I think you are.
+
+> > Run-time rules
+> > break privacy all the time.  (Which is why our allergy to breaking
+> > privacy is kind of silly -- we can always avoid privacy breaking by
+> > turning a compile-time rule into a run-time check, which doesn't
+> > benefit users.)
+> >
+> > I don't see any legality rule here that breaks privacy.  Am I
+> > missing something?  The return-by-copy/return-by-reference
+> > difference breaks privacy, but that's run time.  The accessibility
+> > check breaks privacy, but that too is run time.
+>
+> Huh? 95% of accessibility checks are caught by the static check.
+
+That's true, but...
+
+>...All
+> accessibility checks include a paired static check and dynamic check.
+
+No, not this one.  So not "All".
+
+The rule in question is 6.5(17).  Note that we're talking about the 1995 RM
+ -- the newer version says "Paragraphs 9 through 20 were deleted."
+
+There is no static rule corresponding to 6.5(17) in the 1995 version, hence
+no (static) privacy breaking.
+
+If you disagree, please quote the static rule from RM-95.
+
+> >  I'm looking at the 1995 AARM, and I see only two legality rules in
+> > 6.5, neither of which break privacy.
+> >
+> > I repeat:  My example is legal, and does not raise an exception, in
+> > both Ada 83 and Ada 95.  There is no privacy-breaking legality rule
+> > involved.  We made that example illegal in Ada 2005 (and 2012) ONLY
+> > because we were shy of breaking privacy.
+>
+> I really don't care what this example does at runtime (that's not a
+> compatibility issue, and that's ALL we're talking about here).
+
+Huh?
+
+(I agree with you that "Huh?" should not be taken as an insult.  ;-) I just
+don't have any idea what you're getting at in the above, nor in the following.)
+
+> I agree THIS particular example is legal, but I was noting that the
+> matching return-by-reference case could not be legal, since it
+> necessarily fails a static accessibility check. Which makes the rule
+> privacy-breaking.
+  ^^^^^^^^ Which rule are you saying breaks privacy?  In 1995!
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  11:38 PM
+
+> > > Are you mixing up compile time and run time?
+> >
+> > Definitely not.
+>
+> I think you are.
+
+Certainly not; compatibility is *only* about compile-time rules. For the
+purposes of this discussion, what happens at runtime is completely irrelevant.
+
+...
+> > > I don't see any legality rule here that breaks privacy.  Am I
+> > > missing something?  The return-by-copy/return-by-reference
+> > > difference breaks privacy, but that's run time.  The accessibility
+> > > check breaks privacy, but that too is run time.
+> >
+> > Huh? 95% of accessibility checks are caught by the static check.
+>
+> That's true, but...
+>
+> >...All
+> > accessibility checks include a paired static check and
+> dynamic check.
+>
+> No, not this one.  So not "All".
+
+So you're telling me that this rule violates the design of accessibility checks?
+
+> The rule in question is 6.5(17).  Note that we're talking about the
+> 1995 RM -- the newer version says "Paragraphs 9 through 20 were
+> deleted."
+>
+> There is no static rule corresponding to 6.5(17) in the 1995 version,
+> hence no (static) privacy breaking.
+
+I thought the static rules were implicit in Ada 95. (Meaning that they were
+defined by a blanket rule somewhere.) Maybe I've just gotten senile. :-)
+
+I know that Janus/Ada rejected that example (return-by-reference form) when
+I ran into it in Claw. Perhaps that was a bug, and maybe it was changed since
+(I didn't check), but rejecting it saved me a huge amount of time trying to
+figure what the heck was the problem -- I'd still be trying to get that code
+to work.
+
+> If you disagree, please quote the static rule from RM-95.
+
+Not worth the effort, honestly. It would take 2 hours of reading, and I see no
+point in an issue that was decided long ago.
+
+...
+> > > I repeat:  My example is legal, and does not raise an exception,
+> > > in both Ada 83 and Ada 95.
+
+And I agree. It's the return-by-reference case that's not legal (or shouldn't
+have been legal, take your pick).
+
+...
+> > I really don't care what this example does at runtime (that's not a
+> > compatibility issue, and that's ALL we're talking about here).
+>
+> Huh?
+>
+> (I agree with you that "Huh?" should not be taken as an insult.  ;-) I
+> just don't have any idea what you're getting at in the above, nor in
+> the following.)
+
+We're talking about compatibility; for that, only compile-time checks matter.
+I don't care whatsoever what it does at runtime, be it return-by-copy,
+return-by-reference, return-by-name, return-by-exception, or return-by-ufo.
+The only thing that matters for compatibility is whether or not it is legal.
+(Inconsistency is another deal altogether, but that's not the point here.)
+
+You keep talking about return-by-copy. That has nothing to do with whether
+or not it is legal. It probably has something to do with how likely it is to
+occur in actual practice, and that's a useful data point, but in terms of
+incompatibility it is irrelevant.
+
+If you had simply said in the first place, "that's not illegal because there
+is no static accessibility check FOR ANY TYPE", we'd have had a very different
+discussion, because that's a very different claim. But your focusing on "my
+example is legal" which is "return-by-copy" made it sound to me like you were
+claiming that other examples had different legality (again, that's the only
+thing that matter for compatibility).
+
+> > I agree THIS particular example is legal, but I was noting that the
+> > matching return-by-reference case could not be legal, since it
+> > necessarily fails a static accessibility check. Which makes the rule
+> > privacy-breaking.
+>                                           ^^^^^^^^ Which rule are you
+> saying breaks privacy?  In 1995!
+
+The static accessibility check. There's one implied by the Dewar rule if
+nothing else (unconditionally raising Program_Error is always madness, that's
+even dumber than unconditionally raising Constraint_Error). Maybe I'm the one
+who is mad. Anyway, this is gotten to be a complete waste of time - we're not
+changing any rules here now. So let's stop.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, January 28, 2015  10:23 AM
+
+
+> We're talking about compatibility; for that, only compile-time checks
+> matter. I don't care whatsoever what it does at runtime, be it
+> return-by-copy, return-by-reference, return-by-name,
+> return-by-exception, or return-by-ufo. The only thing that matters for
+> compatibility is whether or not it is legal. (Inconsistency is another
+> deal altogether, but that's not the point here.)
+
+Now I see part of why I was confused -- we're using the term "compatible"
+differently!  To me, inconsistencies are a subset of incompatibilities.  I
+just looked it up in the AARM, and it agrees with me (not surprising, since I
+wrote that part) 1.1.2:
+
+                         Inconsistencies With Ada 83
+
+39.b        This heading lists all of the upward inconsistencies between Ada
+            83 and Ada 95. Upward inconsistencies are situations in which a
+            legal Ada 83 program is a legal Ada 95 program with different
+            semantics. This type of upward incompatibility is the worst type
+                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+            for users, so we only tolerate it in rare situations.
+
+So I suggest you change the way you're using the terms (as non-overlapping categories).
+
+> So let's stop.
+
+OK.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, January 28, 2015  10:51 AM
+
+> > We're talking about compatibility; for that, only compile-time
+> > checks matter. I don't care whatsoever what it does at runtime, be
+> > it return-by-copy, return-by-reference, return-by-name,
+> > return-by-exception, or return-by-ufo. The only thing that matters
+> > for compatibility is whether or not it is legal. (Inconsistency is
+> > another deal altogether, but that's not the point here.)
+>
+> Now I see part of why I was confused -- we're using the term
+> "compatible" differently!  To me, inconsistencies are a subset of
+> incompatibilities.
+
+Maybe informally. But as lead AARM author, I have to document them
+separarately. In the case where there is both compile-time and run-time
+incompatibility, we document that as an inconsistency.
+
+> I just looked it up in the
+> AARM, and it agrees with me (not surprising, since I wrote that part)
+> 1.1.2:
+>
+>                          Inconsistencies With Ada 83
+>
+> 39.b        This heading lists all of the upward inconsistencies between
+Ada
+>             83 and Ada 95. Upward inconsistencies are situations in
+> which
+a
+>             legal Ada 83 program is a legal Ada 95 program with different
+>             semantics. This type of upward incompatibility is the
+> worst
+type
+>                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+>             for users, so we only tolerate it in rare situations.
+>
+> So I suggest you change the way you're using the terms (as
+> non-overlapping categories).
+
+Can't do that, as in that case the AARM no longer would make any sense. Your
+wording above is a tautology; as such it can only be understood if you read
+"incompatibility" informally.
+
+And of course, in causal conversation, the English meaning of "incompatibility"
+(which you're using above) certainly as you say. But I try to never use words
+informally here when they have formal meanings. Conversation here (which is
+usually on the record, after all) is best if not informal.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  11:00 AM
+
+> Maybe informally. But as lead AARM author, I have to document them
+> separarately. In the case where there is both compile-time and
+> run-time incompatibility, we document that as an inconsistency.
+
+I disagree, the idea of incompatibility not including what you call
+inconsistency makes ZERO sense. I have no problem in using phrases like
+compile-time-incompatibility or run-time-incompatibility.
+But to use incompatibility to imply compile time, which is what I understand
+your position to be, is plain wrong and confusing IMO
+
+***************************************************************
+
+From: Bob Duff
+Sent: Wednesday, January 28, 2015  11:23 AM
+
+> And of course, in causal conversation, the English meaning of
+> "incompatibility" (which you're using above) certainly as you say. But
+> I try to never use words informally here when they have formal meanings.
+> Conversation here (which is usually on the record, after all) is best
+> if not informal.
+
+Argh!  The formal meaning matches the informal one!  Yes, the two types of
+incompatibility are listed separately, but so what?  In addition to the
+wording above, we have:
+
+                        Incompatibilities With Ada 83
+
+39.e        This heading lists all of the upward incompatibilities between Ada
+            83 and Ada 95, except for the ones listed under "
+                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+            Inconsistencies With Ada 83" above. These are the situations in
+            ^^^^^^^^^^^^^^^
+            which a legal Ada 83 program is illegal in Ada 95. We do not
+            generally consider a change that turns erroneous execution into an
+            exception, or into an illegality, to be upwardly incompatible.
+
+It is crystal clear in the AARM that "inconsistency" is a subset of "incompatibility".
+
+So PLEASE, stop using these terms in your idiosyncratic and confusing way!
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  11:33 AM
+
+> It is crystal clear in the AARM that "inconsistency" is a subset of
+> "incompatibility".
+
+Furthermore, any other view makes ZERO sense, inconsistencies are certainly
+incompatibilities, and furthermore they are incompatibilities of the worst
+possible kind.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 30, 2015  5:41 PM
+
+...
+> It is crystal clear in the AARM that "inconsistency" is a subset of
+> "incompatibility".
+>
+> So PLEASE, stop using these terms in your idiosyncratic and confusing
+> way!
+
+You're making a mountain out of a molehill.
+
+There is no confusion in the vast majority of messages here, simply because
+we have almost no reason to talk about inconsistencies (run-time
+incompatibilities). That's because we have a near-zero tolerance for them, as
+they potentially make the rocket go off course when the software is recompiled
+(or perhaps make the spam filter pass virii, to take a more realistic example
+of something that could get recompiled with little change or oversight).
+
+We've only tolerated them in two cases: (1) where the previously language is
+nonsense or ill-defined; (2) where the change is expected to mostly fix bugs
+as the new behavior is more like what programmers expect. [I'm actually
+surprised at (2), given the sorts of things Robert talks about here, but we
+ did the untagged equality in large part because of Robert's strong support.
+I probably would have voted against otherwise.]
+
+So the only reasons to talk about inconsistencies here are to (A) justify
+something as either (1) or (2), or to reject an idea based on it being neither
+(1) nor (2). Usually that is a very short discussion (only justifying something
+as (2) potentially needs any discussion).
+
+[Aside: probably the overriding principle is that any inconsistencies that we
+allow shouldn't be any more significant than what could happen from basic
+compiler maintenance (from one version to the next). For instance, improved
+code performance can expose a race condition that had remained hidden in
+previous compiler versions because the code was slow enough that it never
+occurred. No run-time behavior that the Standard changes should be more likely
+than that sort of problem.]
+
+My point is that the only kind of incompatibilities that are even interesting
+here (ARG List) are the compile-time kind. We tolerate more of those because
+no system that doesn't compile is going to malfunction. :-) Exactly how much
+we should tolerate is, of course, open to discussion. [We probably got it
+wrong in the limited return case.]
+
+And, to bring this back to topic, "suppressible errors" only can possibly
+eliminate compile-time incompatibilities. They can't do anything for
+inconsistencies, and indeed they might expose some that are otherwise hidden.
+So I don't see any reason that I should care about any run-time effects where
+we're specifically talking about "suppressible errors"; they can only be a
+negative, not a positive for that.
+
+In that case, we're using "incompatibility" in the effectively the same way.
+And we all know what "inconsistency" means in this context, so we can use
+that in the rare case that it matters.
+
+Similarly, in the limited return example we were talking about, we would
+never have tolerated an inconsistency (a run-time incompatibility, if you
+must). If the compile-time incompatibility was unacceptable, then we would
+have had to (A) break privacy [definitely unacceptable at the time, quite
+possibly still unacceptable], or (B) create a new feature for constructors.
+[IMHO, we should have done (B). Several of us held out on that a long time,
+I was eventually convinced that it was too close to existing functions and
+that I wasn't going to win the separate feature debate - but of course that
+didn't take the (compile-time) incompatibility into sufficient account.]
+There is no circumstance where a run-time incompatibility would ever have been
+tolerated for that feature (and that remains true, IMHO). So there is nothing
+to talk about in that realm; OF COURSE the behavior would be unchanged from
+Ada 95, or it would be illegal. There are no other choices (since this is
+certainly neither of the exceptions where an inconsistency would be allowed
+noted at the start of this message). So I remain perplexed why you were so
+fixed that - it's irrelevant. The only thing we could ever have varied is the
+compile-time incompatibility, nothing else is even an option for the language
+standard. (GNAT, of course, could do something different; it would be sad but
+understandable.)
+
+I'll try to qualify "incompatibility" with "compile-time" when it really
+matters (as I did above), but I make no promises to remember every time.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Friday, January 30, 2015  6:33 PM
+
+> You're making a mountain out of a molehill.
+
+Perhaps, but we recently had a hugely unproductive argument, based on our
+mutual misunderstanding of each others' use of the term.
+
+> There is no confusion in the vast majority of messages here, simply
+> because we have almost no reason to talk about inconsistencies
+> (run-time incompatibilities). That's because we have a near-zero
+> tolerance for them, as they potentially make the rocket go off course
+> when the software is recompiled (or perhaps make the spam filter pass
+> virii, to take a more realistic example of something that could get
+> recompiled with little change or oversight).
+
+Agreed.  There are 49 "Inconsistencies" documented in the AARM.
+Not too many, considering it's a 100,000-line+ document.
+
+> I'll try to qualify "incompatibility" with "compile-time" when it
+> really matters (as I did above), but I make no promises to remember every time.
+
+Fair enough.  Thank you!
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 30, 2015  6:56 PM
+
+> Agreed.  There are 49 "Inconsistencies" documented in the AARM.
+> Not too many, considering it's a 100,000-line+ document.
+
+Well, Word says that Draft 5 (the most current published document) of the AARM
+has 90,344 lines. So you've overestimated by 10%. :-)  [Also, it has 55,667
+paragraphs, 640,755 words, and 4,455,499 characters including spaces (3,739,586
+without spaces). That's probably more than you ever wanted to know about the
+size of the AARM. Of course, an AARM with changes shown would be bigger, but I
+didn't think counting deleted text made much sense in this case.]
+
+And, looking at the index in Draft 5, there are 18 inconsistencies vs Ada 2005,
+19 vs Ada 2012, 15 against Ada 83, and 15 against Ada 95 (so I got 48 in Ada
+2012, 67 in current Ada -- probably there are so many new ones because I've
+been pretty pedantic about documenting them. Most are cases where we forgot
+checks or had too many, not really significant in practice. And I probably
+counted wrong somewhere which explains why you have one more for Ada 2012. :-).
+
+***************************************************************
+
 From: Jeff Cousins
 Sent: Tuesday, January 27, 2015  10:00 AM
 
@@ -7343,3 +8141,265 @@
 
 ***************************************************************
 
+From: Bob Duff
+Sent: Tuesday, January 27, 2015  6:53 PM
+
+> > > My pet RM recommended warning would be for mis-matched constraints
+> > > on renames.
+> >
+> > That's reasonable.
+> >
+> > But in practice, if you want warnings, it's quicker to ask AdaCore
+> > than to require it in the RM.  ;-)
+>
+> But this seems like a case that tailor-made for Suppressible Errors.
+> Here's a rule that we know is stupid (static matching should have been
+> required; the thread that Goodenough dug up shows that the only reason
+> it is the way it is was that Ichbiah didn't want to define something
+> like static matching
+> -- once that was done in Ada 95, no further reason remains), but we
+> can't change it because it would be seriously incompatible. One could
+> easily imagine defining it as a suppressible error, and then allow
+> reverting to the old rules if suppressed.
+>
+> That would actually let us get rid of a wart.
+
+Yes, good idea.
+
+But I don't think your history is quite right.  I think there were some cases
+in Ada 83 where you could NOT statically match, because of restrictions on
+'Base.  To get this right, we'd need to study whether 1995 rules about 'Base
+solve the problem, and if not fix them somehow.
+(Allow more 'Base, or exempt those cases from the rule.)
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 27, 2015  8:05 PM
+
+> But this seems like a case that tailor-made for Suppressible Errors.
+> Here's a rule that we know is stupid (static matching should have been
+> required; the thread that Goodenough dug up shows that the only reason
+> it is the way it is was that Ichbiah didn't want to define something
+> like static matching
+> -- once that was done in Ada 95, no further reason remains), but we
+> can't change it because it would be seriously incompatible. One could
+> easily imagine defining it as a suppressible error, and then allow
+> reverting to the old rules if suppressed.
+
+Sure, but Bob is right, if you really want a warning, ask AdaCore.
+Putting it in Ada 2020 as a suppressible error might satisfy some one's feeling
+of aesthetic consistency, but isn't really helpful :-)
+
+BTW, I find a similar big surprise is that Positive'Image does not work as
+expected, we have customers all the time puzzled by this..
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 27, 2015  9:22 PM
+
+> But this seems like a case that tailor-made for Suppressible Errors.
+> Here's a rule that we know is stupid (static matching should have been
+> required; the thread that Goodenough dug up shows that the only reason
+> it is the way it is was that Ichbiah didn't want to define something
+> like static matching
+> -- once that was done in Ada 95, no further reason remains),...
+
+Generic matching and renames generally use the same rules.  I would argue that
+for generic matching, the relative looseness in matching of formal subprograms
+is a feature, and it would be quite incompatible to change that.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  11:05 PM
+
+> Yes, good idea.
+>
+> But I don't think your history is quite right.
+
+My history is right :-), but whether the exact static matching rules that we
+actually have in Ada would work unmodified is a different issue. That doesn't
+have anything to do with the historical issue -- after all, the devil is always
+in the details.
+
+> I think there
+> were some cases in Ada 83 where you could NOT statically match,
+> because of restrictions on 'Base.  To get this right, we'd need to
+> study whether
+> 1995 rules about 'Base solve the problem, and if not fix them somehow.
+> (Allow more 'Base, or exempt those cases from the rule.)
+
+Last time we looked at this, we would have exempted 'Base from the rules.
+
+In particular, the formal definition of operator symbols typically looks
+like:
+
+     function "*" (Left, Right : in My_Int'Base) return My_Int'Base;
+
+but people would be seriously surprised if
+
+     function "*" (Left, Right : in P.My_Int) return P.My_Int renames P."*";
+
+didn't work. We had planned an exception to the rule to allow this (and only
+this - My_Int has to be a first subtype) to work. But the whole idea didn't
+fly; we'd need it to be a Suppressible Legality Rule.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  11:08 PM
+
+> Sure, but Bob is right, if you really want a warning, ask AdaCore.
+> Putting it in Ada 2020 as a suppressible error might satisfy some
+> one's feeling of aesthetic consistency, but isn't really helpful :-)
+
+It would be helpful because it would change the default from correct (and a
+warning) to illegal (and allowable if necessary). People that always run GNAT
+in warnings-as-error mode wouldn't see any difference, but everyone else would.
+And this is a real bane to understanding Ada code (you have to ignore the
+renames and go back to the original declaration, but how many people truly
+remember to do that?)
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  11:16 PM
+
+> Generic matching and renames generally use the same rules.
+
+But that seems more like a conceit than anything that's really required. I
+don't see any reason to insist that they're the same (doing that has gotten us
+in trouble in other areas in the past), and I think we really need to consider
+to cut that cord. After all, the majority of the rules are repeated in both
+places; keeping them consistent actually takes work, and for most purposes
+that work just causes incompatibilities.
+
+> I would argue that for generic matching, the relative looseness in
+> matching of formal subprograms is a feature, and it would be quite
+> incompatible to change that.
+
+I disagree that this is a feature - I don't think I've every used it (assuming
+that the T vs. T'Base thing is appropriately fixed - couldn't do this without
+having that). Having declarations with subtypes that lie is just confusing.
+Most such subtypes shouldn't have any constraints, and most formal subprogram
+parameters shouldn't have any constraints, and most actual subprogram
+parameters shouldn't have any constraints, and stuff that violates that is
+just a tripping hazard (to use Bob's term).
+
+Of course, a good compelling example to the contrary could change my mind on
+this one.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  3:03 AM
+
+> Generic matching and renames generally use the same rules.  I would
+> argue that for generic matching, the relative looseness in matching of
+> formal subprograms is a feature, and it would be quite incompatible to
+> change that.
+
+That seems right to me, so what I think is reasonable is for compilers to
+give a warning in the non-generic case. I hardly think this is worth
+formalizing at the ARG level with a "suppressible error", especially since as
+Tuck points out it would create an oddity to do it in one case and not the
+other. Such warning heuristics (guessing what is a likely error, avoiding
+false positives) are more the domain of a compiler than a standard. And it
+is so little effort to add a nice warning to GNAT, compared with debating a
+suppressible error in the standard.
+
+Tuck, feel free to open an AdaCore ticket for this warning if you agree it
+would be useful!
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, January 28, 2015  3:05 AM
+
+> It would be helpful because it would change the default from correct
+> (and a
+> warning) to illegal (and allowable if necessary).
+
+No, the standard has nothing to say about the default operation of a compiler,
+so a compiler decides what standard features are or are not included in the
+default mode. For example, GNAT defaults to the static elaboration model. You
+can get the dynamic model, but only if you set a special switch. I suspect
+that GNAT would take everything that was a suppressible error, and just make
+it a warning category, with a special switch to make this particular warning
+category illegal.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Friday, January 30, 2015  6:34 PM
+
+True, but I was talking about "standard mode", which of course every Ada
+compiler has somehow. And most Ada programmers are aware that GNAT needs some
+options to run in "standard mode", so I doubt there will be much surprise if
+there is one more. :-)
+
+One uses "standard mode" for maximum code portability. If someone is never
+going to use an Ada compiler other than GNAT (or any single compiler for that
+matter), then of course the details of the Ada Standard in general are pretty
+much unimportant to them -- it only matters when multiple implementation are
+in use).
+
+Anyway, I view "suppressible errors" as mainly useful for methodological
+restrictions, specifically cases where the construct has a strong probability
+of being a problem. (The declaration of some entity named Standard is one such
+example.) I'd say there has to be less than a 5% chance that the construct in
+question is not a problem in order for a suppresible error to apply. In such
+cases, it's important that the programmer explicitly take an action to tell
+the compiler and especially future readers that the code is OK and why (local
+object only, too much change at this time, etc.) That's why some sort of
+explicit action to allow the code should be required. (Of course, if there is
+no chance that the construct is useful, then it's just a straight error.)
+
+I'm not much interested in "suppressible errors" in cases that are more grey
+than that, especially not if suppressing the error just exposes an
+inconsistency (run-time incompatibility if you prefer) or erroneous execution.
+Such cases are best left to the implementation, and to informal warning
+messages.
+
+Enforcing proper use of parallel operations seems right in this wheelhouse
+(you'd want explicit overriding of the checks for anything that is likely to
+cause a race condition - but of course it's possible that no such race
+condition is possible, so a straight error is too tough). I suspect similar
+suppression would help to the Global aspect (doing so would allow hiding memo
+functions from the user, but of course they could be hosed if such a function
+is used in a parallel context). I think the rename case is here, too,
+including the similar generic actual case, but I can imagine that not everyone
+would agree.
+
+Anyway, I think you ought to decide on how to handle suppressible errors by
+default once we actually determine which errors are suppressible. They might
+turn out to be much morre obviously errors (if not, I'm not likely to vote to
+put them in at all).
+
+***************************************************************
+
+From: Erhard Ploedereder
+Sent: Wednesday, January 28, 2015  1:25 PM
+
+I had a mailer problem, so this message arrives late or really late for
+the meeting. [Editor's note: It arrived in my inbox an hour and twenty minutes
+after we adjourned the meeting.] A summary of my positions on some of the
+issues...
+
+[Issues associated with other AIs removed - Editor.]
+
+Supressable Errors: Since a compiler is free to have a switch that supresses
+error messages that endanger compatibility with whatever, I definitely do not
+want supressable errors in the language that are supressable only for
+compatibility reasons. (The consequence would be that, no matter how bad a
+newly discovered problem in existing features is, for eternity all such error
+messages would be supressable. In the words of someone else: this is disgusting
+language design. An error should remain an error, requiring a fix.)
+Suppressable errors as a variant of "stern warning": much less resistance on
+my part. Still, compilers have been creating such categories forever. I did it
+in the Eighties. If they are in the category "this will never work (as
+expected)", well, fine.
+
+***************************************************************

Questions? Ask the ACAA Technical Agent