CVS difference for acs/ac-00154.txt

Differences between 1.1 and version 1.2
Log of other versions for file acs/ac-00154.txt

--- acs/ac-00154.txt	2007/12/07 02:38:57	1.1
+++ acs/ac-00154.txt	2008/07/13 01:04:00	1.2
@@ -238,3 +238,184 @@
 
 ****************************************************************
 
+From: Jeff Cousins
+Sent: Friday, May 23, 2008  5:47 AM
+
+One of the guiding rules of Ada is often said to be "no surprises".
+ 
+It therefore comes as some surprise that any constraints given by a
+renaming are ignored.
+ 
+For example:
+ 
+procedure  Long_Name (X: Positive);
+
+-- Conformance of constraints not enforced
+procedure Short_Name (Y : Integer) renames Long_Name;
+
+Short_Name (-1); -- Compiles but raises Constraint_Error when run
+ 
+ 
+I am informed various restrictions on the type mark were considered, but rejected:
+"
+(1)     The type mark must be unconstrained.  Rejected because the type
+        might be invisible where the subtype is visible, and because
+        it would preclude writing subtype marks implying the same
+        constraint.
+ 
+(2)     Requring the type mark be followed by 'BASE; this is saying what
+        is meant, but
+ 
+          - gives an attribute returning a type (whereas at present
+            'BASE must be followed by another attribute, i.e., it
+            modifies the following attribute rather than existing in
+            its own right);
+ 
+        and
+ 
+          - requires radical syntax changes for renaming of subprograms
+            with parameters or results, or an obscure restriction to
+            achieve the same effect.
+ 
+(3)     Demanding "equivalent constraints" requires new equivalence
+        rules, including means for defining "sufficiently equal"
+        floating point values resulting from different expressions.
+ 
+The alternative of not ignoring explicit constraints is also unacceptable;
+if the assignment SML := -1; in the above example did NOT raise CONSTRAINT_ERROR
+then the variable POS would have a negative value ...
+ 
+In summary: in the absence of an acceptable solution, the problem must be accepted.
+"
+ 
+Please could this matter be re-visited?
+Re (2), Ada 2005 has opened up some new possibilities, i.e. 'Base is now allowed
+on its own.
+Re (3), Constraints are most often applied to integer types, generally proving
+problematic in practice for floating types, so a solution that only applied to
+discrete types would still be a big step forward.
+ 
+****************************************************************
+
+From: Randy Brukardt
+Sent: Friday, May 23, 2008  3:03 PM
+
+Based on the fairly recent ARG discussion (from which the ancient e-mail you
+quoted comes), there is no real technical problem here: Ada 95 added static
+matching rules (which Ada 83 did not want to do), and simply requiring static
+matching would work fine without the current anomolies. (And there would be no
+reason to have different rules for different kinds of types).
+
+However, this problem is mostly political. A change to require static matching
+on renames (and various generic formal parameters, for which the rules are
+intentionally the same as renaming) would be incompatible with all previous
+versions of Ada. How incompatible depends on how often this capability actually
+occurs in practice - my personal guess is that it is fairly common. I think
+most people rename operators without using 'Base, and that would become illegal
+if we adopt static matching. One could try to adopt some "holes" in the rule
+to avoid the most common incompatibilities, but that could get very complicated. 
+
+Note that the null exclusion rules for renaming were adopted specifically to
+avoid surprises (rather than following the "tradition" of ignoring constraints),
+and they are very complicated (and for a simple on-off exclusion). 
+
+In any case, the only incompatibilites that we will accept as language maintenance
+are those to fix outright bugs. It is not possible to argue that something that
+is explicitly in the Standard, and has been for 25 years, and has been confirmed
+several times, is a bug. Thus any such change would have to wait for the next
+major revision of Ada -- and there are no plans at this time for such a revision.
+So it will be many years before such an incompatible change could be considered,
+and several more before it would appear in compilers.
+
+****************************************************************
+
+From: Dan Eilers
+Sent: Friday, May 23, 2008  3:31 PM
+
+> Thus any such change would have to wait for the next major revision of 
+> Ada -- and there are no plans at this time for such a revision.
+
+This may be true.  However, WG9's announcement and draft agenda for the
+upcoming meeting says there is a "current project to amend ISO/IEC 8652".
+
+See http://www.open-std.org/JTC1/SC22/WG9/n487.txt
+
+# Report of Ada Rapporteur Group: Edmond Schonberg, Chair #  - including
+items related to the current project to amend ISO/IEC 8652
+
+****************************************************************
+
+From: Robert A. Duff
+Sent: Friday, May 23, 2008  5:24 PM
+
+> One of the guiding rules of Ada is often said to be "no surprises".
+>  
+> It therefore comes as some surprise that any constraints given by a 
+> renaming are ignored.
+
+You are right.  This is a flaw in Ada.  Unfortunately, I think you're decades
+too late.  We can't fix this, because it would be severely incompatible.
+
+For ex:
+
+    package P is
+        type T is range ...;
+        ...
+    end P;
+
+    with P;
+    procedure Q is
+        function "+" (X, Y : P.T) return P.T renames P."+";
+
+would be illegal (P.T should be P.T'Base).
+
+I think you are a customer of AdaCore.  You could request that AdaCore implement
+a warning in the "surprising" cases.
+
+The Ada RM doesn't really have the concept of "warning".
+
+On the other hand, AARM-2.8 says:
+
+                           Implementation Requirements
+
+  13    The implementation shall give a warning message for an unrecognized
+  pragma name.
+
+      13.a  Ramification: An implementation is also allowed to have modes in
+            which a warning message is suppressed, or in which the presence of
+            an unrecognized pragma is a compile-time error.
+
+On the third hand, "warning" and "error" are not defined in any formal or
+even semi-formal way, so the above is a rather questionable rule.
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, May 28, 2008  9:27 AM
+
+Thanks for your reply Randy.
+
+I appreciate the problem of backward compatibility.  Could not there be a
+configuration pragma saying to check conformance, so that the default behaviour
+would be as before, but such that checking could be switched on?
+
+****************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, May 28, 2008  9:28 AM
+
+Thanks Bob for your suggestion.  GNAT does already give a warning in such problem cases.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Wednesday, May 28, 2008  9:48 AM
+
+A "restrictions" pragma might be feasible.  It sounds like your concerns are
+more about object renaming than about subprogram renaming, and a restriction
+requiring static matching of object subtypes in renaming would seem to be
+reasonable.  Whether this needs to be de-jure standardized, or simply a
+de-facto standard I can't say.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent