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

Differences between 1.5 and version 1.6
Log of other versions for file ai12s/ai12-0144-1.txt

--- ai12s/ai12-0144-1.txt	2016/01/05 06:11:12	1.5
+++ ai12s/ai12-0144-1.txt	2016/01/07 05:02:54	1.6
@@ -1,4 +1,4 @@
-!standard A.5.2(20)                             16-01-04   AI12-0144-1/04
+!standard A.5.2(20)                             16-01-06   AI12-0144-1/05
 !standard A.5.2(32)
 !standard A.5.2(41)
 !class Amendment 14-12-04
@@ -52,6 +52,16 @@
                  Last  : Result_Subtype) return Result_Subtype
      with Post => Random'Result in First .. Last;
 
+Modify A.5.2(32):
+
+  [Editor's note: We delete the last two paragraphs here as all they say is
+  that the function result is in the result subtype, which goes without saying.
+  The actual description of the result is in the Implementation Requirements
+  follow later; the existing text promises to give that without doing so.
+  We remove this text now so that we don't have to give similar text in the
+  description of the new subprogram, where it would be substantially
+  more complicated.]
+
 Add after A.5.2(32):
 
 function Random (Gen   : Generator;
@@ -60,27 +70,17 @@
      with Post => Random'Result in First .. Last;
 
   Obtains the "next" random number from the given generator, relative to its
-  current state, according to an implementation-defined algorithm. The result
-  of the function in an instantiation of Numerics.Discrete_Random is delivered
-  as a value of the generic formal subtype Result_Subtype that makes the
-  postcondition True. If the range First .. Last is a null range, Constraint_Error
-  is raised.
+  current state, according to an implementation-defined algorithm. If the
+  range First .. Last is a null range, Constraint_Error is raised.
 
   [Editor's notes: During the ARG phone meeting of February 26, 2015, it was
   suggested that the null range case raise Program_Error. However,
   Constraint_Error is the existing exception for that (A.5.2.(39)), so we
   used that here.
 
-  The "delivered as a value" wording is intended to echo that of A.5.2(32); it
-  would be odd to leave it out. But it doesn't say anything that isn't required
-  by the specification (and the later implementation requirements). Possibly
-  a better thing to do would be to delete the two sentences of noise from
-  A.5.2(32), and then we don't need it here, either. I didn't do that as it
-  would be more change than necessary, but we could/should consider doing so.
-
   Postconditions are assumed to be a requirement on the body of a subprogram,
   as proposed in AI12-0179-1. If that AI is not approved, then we should not
-  use a postcondition here.
+  use a postcondition here; we'd need some wording instead.
   End Editor's notes.]
 
 Modify A.5.2(41):
@@ -152,6 +152,10 @@
 
 !ACATS test
 
+An ACATS test should be constructed to check that the new function exists and
+works appropriately. Perhaps the card-dealing example mentioned in the
+discussion could be used.
+
 !appendix
 
 !topic Allow random numbers for different discrete subtypes using same generator
@@ -247,7 +251,6 @@
 
 ***************************************************************
 
-
 From: Pascal Obry
 Sent: Thursday, November 6, 2014  4:10 PM
 
@@ -994,11 +997,6 @@
 
 ***************************************************************
 
-From: Randy Brukardt
-Sent: Friday, December 11, 2015  9:33 PM
-
-***************************************************************
-
 From: John Barnes
 Sent: Friday, December 18, 2015  7:26 AM
 
@@ -1019,3 +1017,154 @@
 
 ***************************************************************
 
+From: Randy Brukardt
+Sent: Tuesday, January 5, 2016 12:10 AM
+
+Getting back to the original reason for this thread...
+
+Here's the revised proposed wording section for this AI. I have a question at
+the end...
+
+Add after A.5.2(20):
+
+function Random (Gen   : Generator;
+                 First : Result_Subtype;
+                 Last  : Result_Subtype) return Result_Subtype
+     with Post => Random'Result in First .. Last;
+
+Add after A.5.2(32):
+
+function Random (Gen   : Generator;
+                 First : Result_Subtype;
+                 Last  : Result_Subtype) return Result_Subtype
+     with Post => Random'Result in First .. Last;
+
+  Obtains the "next" random number from the given generator, relative to its
+  current state, according to an implementation-defined algorithm. The result
+  of the function in an instantiation of Numerics.Discrete_Random is delivered
+  as a value of the generic formal subtype Result_Subtype that makes the
+  postcondition True. If the range First .. Last is a null range, Constraint_Error
+  is raised.
+
+Modify A.5.2(41):
+
+  {The *result range* of a Random function, is the range First .. Last for the
+  version of Random with First and Last parameters, and the range of the result
+  subtype otherwise.}
+
+  A sufficiently long sequence of random numbers obtained by successive calls to
+  Random is approximately uniformly distributed over the {result} range [of the
+  result subtype].
+
+Modify A.5.2(42):
+
+  {A}[The] Random function in an instantiation of Numerics.Discrete_Random is
+  guaranteed to yield each value in its result {range}[subtype] in a
+  finite number of calls, provided that the number of such values does not
+  exceed 2 15.
+
+-----------
+
+In the new text for function Random, we have "The result of the function in an
+instantiation of Numerics.Discrete_Random is delivered as a value of the
+generic formal subtype Result_Subtype that makes the postcondition True."
+
+Assuming that we have the blanket rule for postconditions (now proposed in
+AI12-0179-1, not yet posted), this sentence says only that the function meets
+its specification. We *assume* that everywhere in the Standard, so this is
+just noise.
+
+I've continued to include it because this paragraph immediately follows
+A.5.2(32), which has similar wording, which is similarly useful (not at all).
+[In all of these cases, the important information is in the Implementation 
+Requirements portion.]
+
+But it would be better to omit this junk wording -- that was the intent of
+adding a postcondition as I understand it. To make the wording consistent,
+we then would have to delete the existing wording from A.5.2(32).
+Specifically, the 2nd and 3rd sentences of the following paragraph would also
+be dropped as marked:
+
+  Obtains the "next" random number from the given generator, relative to its
+  current state, according to an implementation-defined algorithm. [The result
+  of the function in Numerics.Float_Random is delivered as a value of the
+  subtype Uniformly_Distributed, which is a subtype of the predefined type Float
+  having a range of 0.0 .. 1.0. The result of the function in an instantiation
+  of Numerics.Discrete_Random is delivered as a value of the generic formal
+  subtype Result_Subtype.]
+
+I didn't unilaterally make this change as it seems like more change than is
+necessary, even though I can hardly imagine any more empty verbiage in the
+Standard. (What else would the result of Random be? A lake in southern
+Sheboygan county? Santa Claus?? :-) Who would expect something other than a
+value of its result subtype? Whose details can be read in the specification
+that precedes this text!)
+
+Should I make this slightly larger change, or forget it?
+
+P.S. I'd like to put this AI to bed someday soon. Or does Someday Never
+Come?? :-)
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 5, 2016  2:32 PM
+
+> ... I didn't unilaterally make this change as it seems like more 
+> change than is necessary, even though I can hardly imagine any more 
+> empty verbiage in the Standard. (What else would the result of Random 
+> be? A lake in southern Sheboygan county? Santa Claus?? :-) Who would 
+> expect something other than a value of its result subtype? Whose 
+> details can be read in the specification that precedes this text!)
+
+I have no problem with deleting clearly superfluous wording.  The danger
+of blatantly redundant wording is that the user might think it means more
+than it says, and try to read something extra in it.  So I would agree,
+heave ho!
+
+> Should I make this slightly larger change, or forget it?
+
+OK with me.
+
+***************************************************************
+
+From: Edmond Schonberg
+Sent: Tuesday, January 5, 2016  2:43 PM
+
+>> Should I make this slightly larger change, or forget it?
+> 
+> OK with me.
+
+Thatís what I would call a Talmudic response ...
+
+***************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, January 5, 2016  2:53 PM
+
+Oops.  Deleting the clearly redundant wording is fine if it is not clarifying
+things for the user.
+
+***************************************************************
+
+From: Bob Duff
+Sent: Tuesday, January 5, 2016  4:06 PM
+
+> Assuming that we have the blanket rule for postconditions (now 
+> proposed in AI12-0179-1, not yet posted), this sentence says only that 
+> the function meets its specification. We *assume* that everywhere in 
+> the Standard, so this is just noise.
+
+I agree.  We should never say that a particular procedure obeys its
+postcondition, because that would lead readers to think that maybe other
+procedures don't obey their postcondition. Better to rely on the blanket
+statement. So I agree with your suggested change.
+
+***************************************************************
+
+From: Jeff Cousins
+Sent: Wednesday, January 6, 2016  3:48 AM
+
+I agree for the same reason.
+
+***************************************************************

Questions? Ask the ACAA Technical Agent