CVS difference for ais/ai-00290.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00290.txt

--- ais/ai-00290.txt	2002/07/23 01:05:24	1.3
+++ ais/ai-00290.txt	2003/01/24 04:14:27	1.4
@@ -164,3 +164,101 @@
 right language for an RM description.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 19, 2002  7:50 PM
+
+> Note also that we have in GNAT pragma Pure_Function, so we can get the
+> advantages of making functions pure without the burden of making the
+> whole package Pure.
+
+And there is an "amendment AI" to add the Pure_Function
+pragma to the "standard" set of pragmas, as
+it seems useful and of low implementation
+burden.
+
+The "defining" semantics for a pure function
+is that if you give it the "same" parameters,
+you get back the same result.  This is patently
+false for a random number generator, so it makes
+no sense to make "random" itself pure.
+
+As Robert points out, it is useful to declare
+that a function has the "pure" property, even
+though it might be implemented in terms of "impure"
+units.  That would be the point of the Pure_Function
+pragma.
+
+Note that the Pure_Function pragma will not enforce
+any restrictions.  It simply informs the reader and
+the compiler that it may omit subsequent calls on
+the function if the inputs are the same, and simply
+reuse the original result.  Note that there is no
+guarantee that if you *had* called the function, it would
+return the same value.  That would be a bug if it
+didn't, presumably, but not erroneous.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 19, 2002  7:55 PM
+
+As mentioned in the earlier response, the important
+thing to remember is that the compiler may omit
+calls on pure functions under certain circumstances,
+and reuse the prior returned value.  It is normally a bug
+to write a pure function that doesn't return the
+same value given the same inputs, but not erroneous.
+
+Another purpose of "Pure" is to support preelaboration.
+A final purpose is to allow packages to be
+freely replicated in a distributed application without
+affecting the semantics.
+
+In retrospect, it was probably a mistake to try to
+make the single concept of "Purity" serve all three
+roles.  They sometimes conflict with one another.
+
+The Pure_Function pragma is a way to loosen the connection a
+bit between these three roles.
+
+****************************************************************
+
+From: Jean-Pierre Rosen
+Sent: Wednesday, November 20, 2002  10:46 AM
+
+Bounded_Error presumably ?
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Wednesday, November 20, 2002  2:38 PM
+
+> As mentioned in the earlier response, the important
+> thing to remember is that the compiler may omit
+> calls on pure functions under certain circumstances,
+> and reuse the prior returned value.  It is normally a bug
+> to write a pure function that doesn't return the
+> same value given the same inputs, but not erroneous.
+
+It often makes perfectly good sense to return values that are different
+from a technical point of view, but the same from a conceptual point of
+view. A good example is when an access value is returned, and of course
+different pointers might be returned but the conceptual value (the value
+pointed to) is always the same. Simple minded string concatenation for
+example is in this category if you are dealing with say unbounded strings.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Tuesday, November 19, 2002  5:51 PM
+
+No, it is not even a bounded error.  The
+compiler is not allowed to complain if
+it returns a different value.  See
+Robert's example of why it might return
+a different value, even though it is
+"conceptually" pure.
+
+****************************************************************
+

Questions? Ask the ACAA Technical Agent