CVS difference for ais/ai-00290.txt

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

--- ais/ai-00290.txt	2002/03/14 23:47:09	1.1
+++ ais/ai-00290.txt	2002/03/19 01:57:03	1.2
@@ -81,3 +81,86 @@
 > in a set of overloaded functions are to be designated as pure.
 
 ****************************************************************
+
+From: Tucker Taft
+Sent: Friday, March 15, 2002  4:23 PM
+
+Robert Dewar wrote:
+>
+> As Tuck requested:
+>
+> @item pragma Pure_Function
+> @noindent
+> Syntax:
+>
+> @smallexample
+> pragma Pure_Function ([Entity =>] function_LOCAL_NAME);
+> @end smallexample
+>
+> This pragma appears in the same declarative part as a function
+> declaration (or a set of function declarations if more than one
+> overloaded declaration exists, in which case the pragma applies
+> to all entities).  If specifies that the function @code{Entity} is
+> to be considered pure for the purposes of code generation.  This means
+> that the compiler can assume that there are no side effects, and
+> in particular that two calls with identical arguments produce the
+> same result.  It also means that the function can be used in an
+> address clause.
+
+For the RM description, I might recommend a different approach.  Probably start
+with the existing rule in 10.2.1(18), where it allows the
+compiler to omit a call if the results are not needed, and to reuse
+the results of a prior call if the parameters are the "same."
+But it would also be useful to go further, and say that the compiler
+may reuse the results of a prior call even if some of the parameters
+might have changed, so long as the only way they could have changed
+is by side-effects of calls on intervening pure subprograms.
+This means that the compiler doesn't have to look inside
+pure subprograms to see what they might have changed, for the purposes
+of eliminating calls on other pure subprograms.
+
+An important feature of the current 10.2.1(18) wording, in my view,
+is that it doesn't allow the compiler to "assume" anything which might
+turn out to be false, and thereby lead to erroneousness.  It simply
+allows the compiler to omit certain calls, and reuse earlier results.
+For example, it can't call the same pure function twice, and omit a check
+on the second call just because the result of the first call passed
+the check.  It has to reuse the result of the first call (which it
+checked directly) if it wants to omit the check that might normally
+be associated with the second call.
+
+> ...
+
+> @findex Pure
+> Note: Most functions in a @code{Pure} package are automatically pure, and
+> there is no need to use pragma @code{Pure_Function} for such functions.  An
+> exception is any function that has at least one formal of type
+> @code{System.Address} or a type derived from it.  Such functions are not
+> considered pure by default, since the compiler assumes that the
+> @code{Address} parameter may be functioning as a pointer and that the
+> referenced data may change even if the address value does not.  The use
+> of pragma @code{Pure_Function} for such a function will override this default
+> assumption, and cause the compiler to treat such a function as pure.
+
+This discussion seems to be inappropriate for the normative semantics
+of the potential amendment.  It might be appropriate to implementation
+advice, or perhaps simply to a particular implementation's documentation.
+
+I would hope that every function in a declared Pure package is at
+least "officially" Pure, independent of whether it has an Address parameter.
+GNAT might choose to not take advantage of the permissions given by
+10.2.1(18) in cases where there is an Address parameter, but clearly
+some compilers may already be eliminating calls on Pure functions
+with Address parameters, and it seems inappropriate to change that
+now.
+
+****************************************************************
+
+From: Robert Dewar
+Sent: Friday, March 15, 2002  5:15 PM
+
+Just to be clear, I am offering the current documentation of the pragma
+in the GNAT documentation, but certainly not suggesting that this is the
+right language for an RM description.
+
+****************************************************************

Questions? Ask the ACAA Technical Agent