Re: Function PRESENT and logical combinations

From: James Giles (
Date: 06/16/04

Date: Wed, 16 Jun 2004 18:58:07 GMT

Janne Blomqvist wrote:
> James Giles wrote:
>> It can if it can prove that F has no side-effects on X,
>> some COMMON or MODULE variable, or some SAVEd
>> internal value, and that it does no I/O. The rule is that the
>> program must behave as if the execution sequence was
>> followed. That's well defined by the standard. Similarly
>> for your other examples. No compiler I know of violates
>> this.
>> If F is declared PURE, then the processor is free to assume
>> all those properties.
> What about FP exceptions? The flags marking these are in a sense
> global variables, no?

But, PURE functions are not allowed to define or redefine any
'global' variables. So, if you regard these flags as being such
variables, shouldn't a PURE procedure be disallowed from
setting them?

The original purpose of PURE functions was to support parallel
execution of programs. In such a case, the concept of "execution
sequence" is stretched to the limit anyway. This probably is a
case that needs further clarification. Of course, the resolution
of the issue is likely to create evem more cases where the
execution of the procedure *can't* be elided. Most implementations
don't skip execution of functions in case that even I agree it's allowed.
It's not really all that common an optimization, so the amount of
diiscussion it receives is disproportionate. (I wouldn't argue it
at all, except that the specific form of the position taken by the
usual opponents would explicitly undefine function references
and even expressions within the language, making their meaning
completely implementation dependent. This seems to me to be
directy opposed to the very purpose of language standardization
in the first place. And, in any case, means that large sections of
the standard document may as well be just deleted, because the
implementation would be free to do things "otherwise" anyway.)

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