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

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

--- ai12s/ai12-0092-1.txt	2015/01/27 03:25:40	1.7
+++ ai12s/ai12-0092-1.txt	2015/01/28 00:11:24	1.8
@@ -6834,6 +6834,23 @@
 
 ***************************************************************
 
+From: Bob Duff
+Sent: Tuesday, January 27, 2015  10:19 AM
+
+> We lost this one several times at the WG-9 level.  The EU has more
+> votes than the US! ;-)
+
+I know, but we should try again with the Suppressible Legality Rules idea.
+Don't call it "unreserved keywords".  Call it reserved words, it's illegal to
+use them as normal identifiers.  But the fine print ;-) says that's a
+suppressible rule (for some of them).  Surely if somebody doesn't like X, and we
+require a compile-time error message for X, they should be happy.
+
+Also, Robert has said all it takes is some debating tactics.
+So we should Robert to a WG9 meeting to push it through.
+
+***************************************************************
+
 From: Randy Brukardt
 Sent: Monday, January 26, 2015  4:07 PM
 
@@ -7021,6 +7038,308 @@
 Could be more fun than reading the ARG list. ;-) We just got an inch of snow
 yesterday and are supposed to get another inch tonight. And temps just below
 freezing (no deep-freeze, knock wood). I think we're getting off easy.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 27, 2015  10:22 AM
+
+> I made the mistake of thinking that Ada 95 didn't have any
+> privacy-breaking Legality Rules (because I didn't remember any).
+>
+> But clearly this case is privacy-breaking (I just went and looked it
+> up with old wording, it's crystal-clear that it breaks privacy). So we
+> could have retained that privacy-breaking to reduce the
+> incompatibility. Not sure why we didn't (perhaps Pascal was looking
+> forward to getting rid of a hack in their compiler? :-).
+
+???
+
+Are you mixing up compile time and run time?  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.  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.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  5:19 PM
+
+> Are you mixing up compile time and run time?
+
+Definitely not.
+
+> 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. All
+accessibility checks include a paired static check and dynamic check.
+
+>  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). 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.
+
+I understand your point, as the number of return-by-reference functions is very
+small. (The one time I was forced into writing one, it took me almost an entire
+working day to get something legal; it was supposed to be a simple replacement
+for the fact that Ada 95 did not allow deferred constants of tagged limited
+types.) But the incompatibility hits far more cases (anything with a limited
+private type in it). I don't remember if we considered that, because if we had,
+we should have realized it was unacceptable (there are a lot of limited private
+types in Ada 83 code, because there wasn't any other way to deal with types that
+needed adjustment on assignment).
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 27, 2015  5:30 PM
+
+> Huh? 95% of accessibility checks are caught by the static check. All
+> accessibility checks include a paired static check and dynamic check.
+
+Well Huh? always reads a bit rude to me, but where on earth does your figure of
+95% come from
+
+> 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).
+> 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.
+
+Right, but you shouldn't throw out A because unrelated B is a problem!
+
+> I understand your point, as the number of return-by-reference
+> functions is very small. (The one time I was forced into writing one,
+> it took me almost an entire working day to get something legal; it was
+> supposed to be a simple replacement for the fact that Ada 95 did not
+> allow deferred constants of tagged limited types.) But the
+> incompatibility hits far more cases (anything with a limited private
+> type in it). I don't remember if we considered that, because if we
+> had, we should have realized it was unacceptable (there are a lot of
+> limited private types in Ada 83 code, because there wasn't any other way to
+> deal with types that needed adjustment on assignment).
+
+I think most of our users just bumped into this accidentally, e.g.
+returning a Text_IO file if I remember one case???
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  5:59 PM
+
+> > Huh? 95% of accessibility checks are caught by the static check. All
+> > accessibility checks include a paired static check and dynamic check.
+>
+> Well Huh? always reads a bit rude to me, but where on earth does your
+> figure of 95% come from
+
+"Huh?" is just an expression of surprise/confusion to me. It might mean that
+someone's being stupid, but there's no implied value judgment as to which of the
+correspondents that is (it might very well be me).
+
+As far as the 95% goes, that's just based on the fact that (in Ada 95, which is
+what we were talking about) there are only two ways to get a dynamic
+accessibility accessibility check - either do something involving an anonymous
+access parameter, or do something involving a check in a generic body. The
+latter is dynamic in name only for a compiler like GNAT (it is dynamic in
+Janus/Ada, but that's the rare case), and the former shouldn't happen very often
+as potential for failure of such checks is like pointing a giant cannon at your
+head and giving someone you don't like the lanyard. :-) I'd guess the vast
+majority of cases of the latter are by accident (that surely has been the case
+with me, mostly because Ada didn't allow in out parameters on functions).
+
+I don't think Ada 2012 changes this dynamic much; the major cause of problems
+can be eliminated by using "in out" parameters on functions, but now there are a
+couple of new ones involving aliased parameters and class-wide function returns
+and of course SAOAATs (stand-alone objects of an anonymous access type). Most of
+these new cases are very unlikely to occur in practice. (I do worry about the
+class-wide return case somewhat.)
+
+This is one of the reasons that I continue to resist the temptation to fill in
+the various missing dynamic accessibility tests in the ACATS. Those objectives
+are almost completely untested, but with the possible exception of the
+class-wide return case, I doubt that they'll ever happen in practice.
+
+...
+> > I understand your point, as the number of return-by-reference
+> > functions is very small. (The one time I was forced into writing
+> > one, it took me almost an entire working day to get something legal;
+> > it was supposed to be a simple replacement for the fact that Ada 95
+> > did not allow deferred constants of tagged limited types.) But the
+> > incompatibility hits far more cases (anything with a limited private
+> > type in it). I don't remember if we considered that, because if we
+> > had, we should have realized it was unacceptable (there are a lot of
+> > limited private types in Ada 83 code, because there wasn't any other
+> > way to deal with types that needed adjustment on assignment).
+>
+> I think most of our users just bumped into this accidentally, e.g.
+> returning a Text_IO file if I remember one case???
+
+Exactly. Limited private types are fairly common, but that alone doesn't trigger
+the return-by-reference rules. The return-by-reference stuff was madness, and
+getting rid of it probably was a good thing, but it's the related cases that had
+nothing to do with that which were the incompatibility that caused problems.
+
+Unfortunately, it has taken until this discussion for me to understand exactly
+why that change was such a problem. Which demonstrates likely why we missed
+that; we were focused on return-by-reference (which is rare) and didn't think
+enough about other cases that would get caught in the net. (I do think someone
+brought that up, but we didn't really realize how wide-spread such things are.)
+
+Anyway, hindsight is 2020; if that's the worst mistake we've ever made, I'm
+pretty pleased with our results. (The odds of working on something as large as
+an Ada revision without making any mistakes is roughly zero, after all.)
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, January 27, 2015  10:00 AM
+
+> Ada 2005 was in my mind pretty much a failure, in that we implemented it, but
+> few users made the transition, and there is no question that the
+> incompatibilities in return of limited types acted as a major barrier.
+
+Thinking just of my projects, overall that change had more negatives than
+positives, but it wasn't any big deal, certainly not enough to prevent moving
+forward.
+
+
+And now that there's a separate thread from 0003...
+
+My pet RM recommended warning would be for mis-matched constraints on renames.
+
+***************************************************************
+
+From: Robert Dewar
+Sent: Tuesday, January 27, 2015  10:04 AM
+
+> My pet RM recommended warning would be for mis-matched constraints on renames.
+
+can you give an example?
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, January 27, 2015  10:18 AM
+
+Bottom of p287/top of p288 of "Programming in Ada 2012".
+GNAT gives warnings at the call of Q, though a warning at the declaration of Q
+would also be nice.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 27, 2015  10:36 AM
+
+> > My pet RM recommended warning would be for mis-matched constraints on renames.
+>
+> can you give an example?
+
+procedure Eg is
+   procedure P (X : Integer) is
+   begin
+      null;
+   end P;
+
+   procedure Q (X : Natural) renames P; -- "Natural" is ignored here.
+begin
+   Q (-1);
+end Eg;
+
+This is legal, and does NOT raise an exception, in all versions of Ada.
+See RM-8.5.4(7).
+
+GNAT has a compiler bug -- it raises Constraint_Error on the call to Q (and
+warns about that at compile time).  I'm not going to open a ticket unless I
+manage to fix all more-important bugs and enhancements.  ;-)
+
+I assume what Jeff is asking for is a warning on the renaming_decl.
+Similar oddities occur for object renamings and perhaps others.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 27, 2015  10:37 AM
+
+> 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.  ;-)
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Tuesday, January 27, 2015  11:30 AM
+
+> procedure Eg is
+>    procedure P (X : Integer) is
+>    begin
+>       null;
+>    end P;
+
+>    procedure Q (X : Natural) renames P; -- "Natural" is ignored here.
+> begin
+>    Q (-1);
+> end Eg;
+
+Integer and Natural the other way round is what I was thinking of, which should
+raise a Constraint_Error, but yes, GNAT gets it wrong for Bob's example.
+
+***************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, January 27, 2015  6:08 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.
 
 ***************************************************************
 

Questions? Ask the ACAA Technical Agent