CVS difference for acs/ac-00154.txt

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

--- acs/ac-00154.txt	2008/07/13 01:04:00	1.2
+++ acs/ac-00154.txt	2009/10/23 04:08:20	1.3
@@ -242,59 +242,59 @@
 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
@@ -313,11 +313,11 @@
 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. 
+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). 
+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
@@ -332,7 +332,7 @@
 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 
+> 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
@@ -349,8 +349,8 @@
 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 
+>
+> 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
@@ -416,6 +416,309 @@
 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.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Monday, June 8, 2009  1:22 PM
+
+!topic Possible ambiguity in subprogram renaming declarationsw
+!reference 8.5.4(7)
+!from Adam Beneschan 09-06-08
+!discussion
+
+The following is extracted from ACATS test B85013C:
+
+PROCEDURE B85013C (N : INTEGER) IS
+
+     I : INTEGER;
+     O : STRING(1 .. 1);
+
+     SUBTYPE S  IS STRING;                        -- UNCONSTRAINED.
+     SUBTYPE S1 IS STRING(1 .. 2);                -- STATIC.
+     SUBTYPE S2 IS STRING(1 .. N);                -- NON-STATIC.
+
+     PROCEDURE P3 (X : S2 := (OTHERS => '*'));    -- OK - S2 CONSTRAINED
+
+     PROCEDURE P4 (X : S1 := ('1', OTHERS => '*'))-- OK.
+                    RENAMES P3;
+
+The declaration of P4 was illegal before Ada 95, but it became legal with Ada 95
+rule changes.  However, I am not 100% clear on what should happen when P4 is
+called (if N is something other than 2).  Since this is a B test and there are
+still other errors in the test, there is no check to make sure the correct
+semantics take place at run time.
+
+8.5.4(7) says that the profile of the new view "takes its subtypes, parameter
+modes, and calling convention from the original profile of the callable entity,
+while taking the formal parameter names and default_expressions from the profile
+given in the subprogram_renaming_declaration."  What is the "default_expression"
+in this case?  Specifically, what is the subtype of the default expression, S1
+or S2?  Which subtype is used to determine the "applicable index constraint" for
+the default expression, as defined by 4.3.3(11)?
+
+My reading is that the constraint of S1 in the renaming declaration doesn't have
+any effect on the semantics of anything, and thus the aggregate ('1',
+others=>'*') as if S2's constraint is the applicable one.  Thus, if N=5, the
+default parameter when P4 is called is actually "1****".  However, GNAT gives a
+Constraint_Error when P4 is called with no explicit parameter, indicating that
+it thinks the default parameter is "1*", which then raises the exception when
+"1*" is converted to subtype S2.  Not that GNAT is always right about
+everything.  But when it gives a result contrary to what I think the RM is
+saying, in a case where the RM isn't completely clear, I think a clarification
+may be necessary.
+
+In fact, if my reading of the RM is correct, this could be very confusing to a
+reader.  (Who, looking at the declaration of P4, would think that the default
+parameter is actually "1****" or something else depending on N?)  So whatever
+the wisdom of allowing parameter/result subtypes in a subprogram renaming
+declaration to be different from that of the renamed subprogram (and ignoring
+the constraints in the renaming declaration), I suspect that perhaps we should
+disallow this in the case of an array constraint.  Perhaps allowing the
+parameter subtype in the renaming declaration to be an unconstrained array
+subtype is OK.  But I think we should consider adding a restriction that if a
+subtype in the profile of a subprogram renaming declaration is a constrained
+array, the constraint must statically match that of the corresponding subtype in
+the renamed callable entity---or something similar.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 8, 2009  2:27 PM
+
+> My reading is that the constraint of S1 in the renaming declaration
+> doesn't have any effect on the semantics of anything, and thus the
+> aggregate ('1', others=>'*') as if S2's constraint is the applicable
+> one.  Thus, if N=5, the default parameter when P4 is called is
+> actually "1****".
+
+I agree.
+
+>....However, GNAT gives a Constraint_Error when P4 is  called with no
+>explicit parameter, indicating that it thinks the  default parameter is
+>"1*", which then raises the exception when "1*"
+> is converted to subtype S2.
+
+Sounds like a bug in GNAT.
+
+>...Not that GNAT is always right about
+> everything.  But when it gives a result contrary to what I think the
+>RM is saying, in a case where the RM isn't completely clear, I think a
+>clarification may be necessary.
+>
+> In fact, if my reading of the RM is correct, this could be very
+> confusing to a reader.
+
+Indeed.  This is IMHO a language design flaw.  It apparently confused somebody
+writing that part of GNAT, sometime in the distant past.
+
+>..(Who, looking at the declaration of P4, would  think that the default
+>parameter is actually "1****" or something else  depending on N?)  So
+>whatever the wisdom of allowing parameter/result  subtypes in a
+>subprogram renaming declaration to be different from  that of the
+>renamed subprogram (and ignoring the constraints in the  renaming
+>declaration), I suspect that perhaps we should disallow this  in the
+>case of an array constraint.  Perhaps allowing the parameter  subtype
+>in the renaming declaration to be an unconstrained array  subtype is
+>OK.  But I think we should consider adding a restriction  that if a
+>subtype in the profile of a subprogram renaming declaration  is a
+>constrained array, the constraint must statically match that of  the
+>corresponding subtype in the renamed callable entity---or  something
+>similar.
+
+Well, perhaps GNAT should give a warning.
+
+But I don't think it's sufficiently broken to fix the language.
+And I think this particular case is no worse than other cases.
+I mean:
+
+    P4 (('1', OTHERS => '*'));
+
+who would expect that subtype S1 is ignored and S2 is used instead?
+I don't much like the idea of fixing just part of the problem.
+
+I also don't understand why you want to allow String in the renaming. That's
+equally confusing -- it makes me think I can pass a string of any length, but I
+can't.
+
+****************************************************************
+
+From: Adam Beneschan
+Sent: Monday, June 8, 2009  2:45 PM
+
+> But I don't think it's sufficiently broken to fix the language.
+> And I think this particular case is no worse than other cases.
+> I mean:
+>
+>     P4 (('1', OTHERS => '*'));
+>
+> who would expect that subtype S1 is ignored and S2 is used instead?
+> I don't much like the idea of fixing just part of the problem.
+
+The way I phrased my proposed solution didn't have anything to do with default
+parameters.  It would make the renaming declaration of P4 (with parameter
+subtype S1) illegal regardless of whether the renaming or renamed subprogram had
+default parameters.
+
+> I also don't understand why you want to allow String in the renaming.
+> That's equally confusing -- it makes me think I can pass a string of
+> any length, but I can't.
+
+I was just trying to discern why it was permitted at all to specify different
+subtypes in the renaming declaration.  If it were me, I probably would have
+required subtype conformance rather than mere mode conformance.  My statement
+about allowing an unconstrained array (String) in the renaming was based on my
+assumption that there was a good reason for allowing the subtypes to be
+different, and guessing that whatever this reason was (which I don't know), it
+might dictate that we should allow an unconstrained array as the parameter
+subtype when that of the renamed subprogram is constrained.  It's just a guess.
+I didn't mean to imply that I *want* the programmer to be able to change the
+subtype to unconstrained.  I don't, really.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Monday, June 8, 2009  3:09 PM
+
+> I was just trying to discern why it was permitted at all to specify
+> different subtypes in the renaming declaration.  If it were me, I
+> probably would have required subtype conformance
+
+There was no notion of subtype conformance in Ada 83, and I think the rule was
+set this way because *something* had to be said about it, and presumably Jean
+thought that anyway, nobody would do it...
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 8, 2009  3:15 PM
+
+> The way I phrased my proposed solution didn't have anything to do with
+> default parameters.
+
+OK, I misread it.  I just reread it, and you propose to restrict the array case.
+I don't see why -- all cases (records, integer, &c) seem equally confusing to
+me.  And fixing the problem would be incompatible.  (Only doing arrays is less
+incompatible, but still incompatible.)
+
+We don't normally add rules that break existing programs, just because those
+programs are confusing.
+
+> I was just trying to discern why it was permitted at all to specify
+> different subtypes in the renaming declaration.
+
+It was discussed during the Ada 83 design, and it was recognized as a problem
+(to ignore subtypes), but there was some reason people thought it had to be that
+way.  I don't remember why.  Maybe this: when you say "type T is range 1..10;"
+you get a "+" function whose parameters are sort-of of the base subtype.  But
+'Base was restricted in Ada 83 -- you can't say:
+
+    function Blah (X: T'Base; ...) ... renames "+";
+
+In Ada 95, 'Base is still restricted (with different restrictions).
+A similar issue would arise for "&".
+
+There might be some generic-related reason(s).  Generic parameter associations
+are supposed to be just like renaming.
+
+>...If it were me, I
+> probably would have required subtype conformance rather than mere mode
+>conformance.
+
+Me, too.
+
+>...My statement about allowing an unconstrained array
+> (String) in the renaming was based on my assumption that there was a
+>good reason for allowing the subtypes to be different, ...
+
+There was a reason.  I don't think it was a "good" reason.  ;-) At least, that's
+what I remember thinking when I read the Ada 83 discussions.  Long time ago.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Monday, June 8, 2009  3:39 PM
+
+John Goodenough was nice enough to unearth the answer to this question a few
+years ago. (This thread was filed in AC-0154.) He found the following message:
+
+
+On June 1, 1982, Kit Lester of the Language Design Team wrote a comment directly
+addressing why constraints are ignored in renaming:
+
+*******************************************
+
+This comment paraphrases a discussion at the November 1981 DR's meeting, for
+those without access to the minutes (LSN.250, pages 6 and 7).  See also comment
+#753 by George Romanski of Ada-Europe.
+
+Many users will be shocked that explicit constraints on type marks appearing in
+renaming declarations of objects or subprograms (or in generic formal
+declarations defined in terms of renaming) will be ignored.  Eg:
+
+        subtype POSITIVE is INTEGER range 1 .. NATURAL'LAST
+        POS : POSITIVE;
+        subtype SMALL is INTEGER range -9 .. +9;
+        SML : SMALL renames POS;  -- legal
+          ...
+        SML := 10;   -- not small, but ok; shock
+        SML := -1;   -- small but raises CONSTRAINT_ERROR; shock
+
+Various restrictions on the type mark have been 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.
+
+-----------------
+
+The net answer is that the Ada 83 team wasn't able (or willing?) to come up with
+a definition of statically matching constraints (alternative fix (3), in Ada 95
+terms), which of course Tucker did add to Ada 95.
+
+The problem now is that requiring static matching of constraints (equivalently,
+subtype conformance) would be wildly incompatible for existing renames. For
+instance, the typical way to write operator renames would be illegal for
+predefined operators:
+
+     function "*" (Left, Right : My_Integer) renames My_Package."*"; -- Illegal:
+                                              -- Does not statically match
+
+     function "*" (Left, Right : My_Integer'Base) renames My_Package."*"; -- OK.
+
+We probably could probably make some complex set of rules that allows common and
+fairly harmless mismatches like the above and eliminate the nastier ones (such
+as the both constrained case that Adam notes here). But that seems like a lot of
+work for something that is mostly going to cause problems for people. If you
+want to try it, please feel free to go ahead and propose something. I'd love to
+see the stupidity reduced here.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent