# Re: Function PRESENT and logical combinations

From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 06/15/04

```Date: Tue, 15 Jun 2004 20:17:20 GMT

```

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
>
> "7.1.8.1 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 7.1.8.1 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.

```--
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
```