# CVS difference for acs/ac-00032.txt

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

```--- acs/ac-00032.txt	2002/04/26 20:15:16	1.1
+++ acs/ac-00032.txt	2002/04/30 21:42:06	1.2
@@ -3,7 +3,7 @@
!subject

-!appendix
+!appendix Preferred interpretations for modular type operations

!topic Modular types, preferred interpretations
!reference RM95-8.6(29),3.5.4(17),4.9(34)
@@ -350,6 +350,16 @@

****************************************************************

+From: Robert Dewar
+Sent: Friday, April 26, 2002  5:45 PM
+
+Well yes, of course we know that, but the original code was just an example
+of a more general problem. Actually this business of whether a user defined
+or universal operator is used can definitely confuse beginners, but it is
+something that experienced Ada programmers should have straight :-)
+
+****************************************************************
+
From: Bob Duff
Sent: Friday, April 26, 2002  8:48 AM

@@ -389,4 +399,292 @@
consistent (implicit "mod" on everything).

****************************************************************
+
+Sent: Friday, April 26, 2002  10:01 PM
+
+Gary Dismukes wrote:
+
+> >
+> > Is the following legal?
+>
+> No.
+>
+> >     type Modular_Type is mod 5;
+> >
+> >     X : Modular_Type := Modular_Type'Modulus - 1;
+> >
+> > ACATS test b490001 indicates that this should be illegal . . .
+>
+> But there isn't any such "-" operator.  Type universal_integer doesn't
+> have such an operation (universal types don't have any primitive operations
+> at all, see 3.4.1(7)).  There is however a "-" operator for type root_integer
+> that results in a possible interpretation.
+
+Thank you for the response.  I was having trouble understanding the
+differences between universal_integer and root_integer and how
+everything fit together, but I believe I'm clear on that now.
+
+If I understand correctly, the specific rule that makes this code
+illegal is 4.9(34)---is that correct?  Since the only allowable
+interpretation of "-" is the predefined operator on the modular type,
+it violates 4.9(34) because the left operand to "-" is out of range
+for the modular type, and therefore fails Range_Check.
+
+But is this right?  11.5(16) defines "Overflow_Check" as checking that
+a scalar value is within the base range of its type.  11.5(17) defines
+"Range_Check" as checking that a scalar value satisfies a range
+constraint, plus some other cases that are irrelevant to this issue.
+
+4.5.3(1-2) indicates that the predefined "-" operator is defined for a
+type, not a subtype.  My understanding was that only subtypes have
+constraints, and types do not; 3.2 and other sections (such as
+3.5.4(10)) bolster this impression.  Thus, when Modular_Type'Modulus
+cannot be used as an argument to "-", it's because the the value is
+not within the base range of the type, *not* because the value does
+not satisfy a range constraint.  So it would seem to me that the
+evaluation of (Modular_Type'Modulus - 1) fails Overflow_Check, not
+Range_Check, and therefore the compiler should *not* reject the
+expression by 4.9(34).
+
+Adding to my confusion is ACATS test c45252a, which contains this
+code:
+
+     TYPE LIKE_DURATION_M23 IS DELTA 0.020 RANGE -86_400.0 .. 86_400.0;
+
+     IF 2.9E9 <= LIKE_DURATION_M23'LAST THEN . . .
+
+On a 32-bit machine, Like_Duration_M23 will likely be implemented as
+an integer with 26 bits to the left of the decimal point and 6 bits to
+the right (Like_Duration_M23'Small = 0.015625).  The base range,
+therefore, would be approximately -3.3E7 .. 3.3E7, so 2.9E9 falls
+outside this base range.  I'm guessing, though, that when 2.9E9 is
+passed as the first parameter to this function:
+
+    function "<=" (Left, Right : T) return Boolean;
+
+where T is the base type of Like_Duration_M23, this is supposed to
+fail Overflow_Check and not Range_Check, because the compiler is *not*
+supposed to flag this as an error.  So in order for c45252a and
+b490001 both to be correct, it would have to be the case that the
+out-of-base-range value fails Overflow_Check in the fixed-point case
+and Range_Check in the modular-type case.  What language rules make
+this the case?
+
+Anyway, I've convinced myself that this *is* indeed the case, but
+perhaps for the wrong reason.  Parameter associations for IN
+parameters involve type conversions, and 4.6(28) says
+
+    If there is no value of the target type that corresponds to the
+    operand value, Constraint_Error is raised; this can only happen on
+    conversion to a modular type, and only when the operand value is
+    outside the base range of the modular type.
+
+So it makes sense that modular types and other types would be treated
+differently.  Still, since this check involves the base range, it
+would seem that a violation would be an Overflow_Check, by 11.5(16).
+But the reason I think it's really a Range_Check is . . . because the
+Index says so.  That is, the Index entry for Range_Check points to
+4.6(28).  This is disturbing, though, because the Index isn't part of
+the Standard.
+
+So unless there's something I'm missing, or unless there's an error in
+one of the ACATS tests, I think the language rules need to be a lot
+clearer regarding what a Range_Check and what an Overflow_Check is, in
+order to know just what is allowed by 4.9(34).
+
+I appreciate any comments anyone has regarding this.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, April 26, 2002  6:21 PM
+
+> I agree that it's a flaw in the language.  Whether it's worth fixing, I
+> don't know.
+
+I disagree that this is a flaw, and I am afraid any attempt to "fix" it would
+make things worse.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, April 26, 2002  10:41 PM
+
+I really don't think there is any interesting language revision issue here.
+Shouldn't questions be directed elsewhere.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Monday, April 29, 2002  3:44 AM
+
+> I'm not sure there's a real "problem", so I'm not sure detecting it
+> earlier is "good".  ;-) Maybe the root of the problem is with type
+> conversion to modular.  Why do all the other operations do an implicit
+> "mod", and this one doesn't?  We argued about that during the language
+> design, and I think perhaps we got the wrong answer in the end.
+>
+> (I don't much like the implicit "mod"'s at all.  But if you're going to
+> have implicit mod on "+" and so forth, it seems like you should have
+> consistency.)
+
+That doesn't strike me as inconsistent.  It seems to me that it nicely mimics
+the mathematical properties of the set of integers modulo m: the operations
+"wrap around", but numbers outside the range 0..m-1 do not belong to the set.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 29, 2002  2:00 PM
+
+The discussion in the Sherwood Forest clearly understood that modular types
+were going to be subject to some issues when it came to modular behavior
+vs overflow behavior. I think that discussion was well informed, and
+reached the right conclusion, i don't see any improved suggestions on
+the table, even discounting compiatibility issues.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, April 29, 2002  4:14 PM
+
+We explicitly discussed the issue of whether explicit or implicit
+conversion should be wrap-around, and I remember Randy providing
+some persuasive scenarios why it was better to not do the
+wraparound on conversion.
+
+If we *did* provide wraparound on conversion, it would probably
+want to be reversible as well, but that is pretty hard to
+define.  For example:
+
+    type Mod_Int is mod 2**Integer'Size;
+    procedure Test(Y : in out Mod_Int) is
+    begin
+        null;
+    end;
+
+    X : Integer := Integer'First;
+  ...
+    Test(Mod_Int(X));
+   -- What is the value of X at this point if conversion is wraparound?
+   -- is it back to Integer'First?
+
+Another reason not to provide wraparound on implicit conversion
+from Universal integer was there would be less help in detecting
+typographical errors, e.g. when writing 16#7FFFFFFFF# (9 digits
+instead of 8) when you should have written 16#7FFFFFFF#.
+
+(The reverse conversion problem seems the more troublesome.)
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 29, 2002  4:33 PM
+
+Indeed, that was the Sherwood Forest discussion I mentioned. Somewhere
+someone should have the minutes of this meeting, though frankly I see no
+reason to rediscuss this issue, nothing new has come up.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 30, 2002  3:26 PM
+
+Robert said:
+
+> The discussion in the Sherwood Forest clearly understood ...
+
+Are you talking about a 9x DR meeting? I don't recall one that located in
+anything like "the Sherwood Forest".
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 30, 2002  3:37 PM
+
+Tuck said:
+
+> We explicitly discussed the issue of whether explicit or implicit
+> conversion should be wrap-around, and I remember Randy providing
+> some persuasive scenarios why it was better to not do the
+> wraparound on conversion.
+
+I don't doubt it. If you are going to have modular types, they have to be
+
+My complaint has always been the impossibility of having an unsigned type
+with the largest integer size and the "safe" overflow semantics of Ada. It
+seems odd that in this one case, you are forced to choose "unsafe" by the
+language. (Yes, there are cases where modular semantics are useful; it
+should be obvious that we need both...)
+
+complaint for a long time, and every time is comes up, we vote it no-action.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Tuesday, April 30, 2002  3:48 PM
+
+> Indeed, that was the Sherwood Forest discussion I mentioned. Somewhere
+> someone should have the minutes of this meeting, though frankly I see no
+> reason to rediscuss this issue, nothing new has come up.
+
+contain all of the MRT e-mail, there doesn't appear to be any archive of
+meeting minutes. Perhaps its in the mail, but I'd need some idea of when
+this meeting took place (I recall a significant discussion of modular types
+after our UI team did a fairly complete implementation, which proved to my
+surprise that non-binary modulii were not hard nor inefficient to implement.
+But that may not be what you have mind.)
+
+****************************************************************
+
+From: Alexandre Kopilovitch
+Sent: Monday, April 29, 2002  4:31 PM
+
+"Pascal Leroy" <pleroy@rational.com> wrote:
+>even if you started a language
+>design from scratch, you could come up with a set of rules that would be free
+>from "unintuitive" consequences.  Of course, you could do what the other
+>languages do, i.e. keep the rules fuzzy enough that it's impossible to reason
+>on their consequences.
+
+There exists another way to deal with such "unintuitive" consequences. Perhaps,
+quite expensive way, but nevertheless valid. Consider a "manifold" notion in
+the differential geometry/topology. A common manifold (sphere, for a example)
+can't be coordinatized as a whole, that is, one can't impose single coordinate
+system that exactly covers the manifold. But several coordinate system easily
+covers the manifold, and when we impose the requirement for these coordinate
+systems to be compatible (in some strict sense) to each other on intersections,
+we obtain a quite useful coordinates, with which we may perform _local_
+computations.
+  Applying this metaphor to a programming language definition, several overlapped
+areas (or "mental modes") may be defined. What is "intuitive" in one area isn't
+necessarily intuitive in another, but all areas follow the same type of logic,
+and inside the interesections, locally, the considerations always look very
+similar, almost isomorphic.
+  This way, all rules can be made "natural" (that is, without "unintuitive"
+consequences - locally, of course) - in at least one area.
+  Not all those areas should be presented in foreground for the real programmers,
+so there is no need to pursue the same detalization of the presentation for
+all areas. Those "shadow", but explicitly defined and outlined areas may be
+useful for 1) references, 2) discussions (like that provoked this message),
+3) extension of a language subsets used for formally provable programs.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Monday, April 29, 2002  4:32 PM
+
+I must comment that I find Alexandre's contribution about general language
+design way off topic, and of little value. Please let's not have general
+philosophical discussions. Take them to some discussion group, where vague
+stuff is not only tolerated but welcome :-)
+
+****************************************************************
+

```

Questions? Ask the ACAA Technical Agent