Re: Function PRESENT and logical combinations
From: Gary L. Scott (garyscott_at_ev1.net)
Date: Tue, 15 Jun 2004 19:22:58 -0500
James Giles wrote:
> Dick Hendrickson wrote:
> > I really don't want to start a long discussion of this, and
> > I'll probably quit after this post. But, the counter
> > argument is in
> > "22.214.171.124 Evaluation of operands
> > It is not necessary for a processor to evaluate all of the
> > operands of an expression, or to evaluate entirely each
> > operand, if the value of the expression can be determined
> > otherwise."
> And, if you'll point to the part of the document that specifies
> what other means there are of determining the value of a
> function, I'll agree that the passage is relevant. The statement
> refers to other parts of §7.1.8, none of which apply to functions.
> The rest of that section does indeed specify other means of
> evaluating *expressions*. If we are to assume that "otherwise"
> refers to means not specified at all by the standard, then
> evaluating expressions is completely undefined.
> > The processor doesn't have to "evaluate each operand",
> > so, in an expression like
> > A = 0 * F(x)
> > the processor might not need to evaluate F(x) and then the
> > side-effects become undefined. [...]
> But this does not constitute a an alternative way of evaluating
> the function, it provides for means of evaluating the *expression*
> as a whole that no longer even references the function. If no
> such alternative means exists, and the function is evaluated,
> that occurs by execution.
> > [... Personally, I think James
> > is basically correct and that "the other side" is placing
> > way too much emphasis on what "can be determined otherwise"
> > could mean. But, it's clear to me that a straight-forward
> > reading of 126.96.36.199 could easily say that functions aren't
> > necessarily evaluated. [...]
> Yes, if the transformations explicitly permitted by the rest of
> §7.8.1 completely eliminate the reference to the function, then
> the function may not be evaluated at all. If the function *is*
> evaluated, either because such transformations are not possible
> or because the implementation just failed take advantage of the
> possibility, that evaluation is by execution of the function.
> > Also, in something like
> > integer, parameter :: sp = KIND(1.0)
> > does anybody think the KIND function is actually "executed"
> > as opposed to having its value "determined otherwise"?
> I do. The production of the value, by whatever means that
> is accomplished, is the whole semantic consequence of executing
> KIND. It therefore completely constitutes an execution of the
> function within the definition of "execution" in the standard.
Clearly it is ambiguous. Let's just define how to fix it (and then fix
it) and move on to more useful topics like what should go into the next
standard. Is there a complete list of proposals so far?
> J. Giles
> "I conclude that there are two ways of constructing a software
> design: One way is to make it so simple that there are obviously
> no deficiencies and the other way is to make it so complicated
> that there are no obvious deficiencies." -- C. A. R. Hoare
-- Gary Scott mailto:firstname.lastname@example.org Fortran Library: http://www.fortranlib.com Support the Original G95 Project: http://www.g95.org -OR- Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html Why are there two? God only knows. Democracy is two wolves and a sheep, voting on what to eat for dinner... Liberty is a well armed sheep contesting the vote. - Thomas Jefferson