Re: Function PRESENT and logical combinations
From: James Giles (jamesgiles_at_worldnet.att.net)
Date: 06/16/04
- Next message: Michael Metcalf: "Re: Fortran 95/2003 Explained (announcement)"
- Previous message: James Giles: "Re: Function PRESENT and logical combinations"
- In reply to: Janne Blomqvist: "Re: Function PRESENT and logical combinations"
- Next in thread: glen herrmannsfeldt: "Re: Function PRESENT and logical combinations"
- Reply: glen herrmannsfeldt: "Re: Function PRESENT and logical combinations"
- Reply: James Giles: "Re: Function PRESENT and logical combinations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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
- Next message: Michael Metcalf: "Re: Fortran 95/2003 Explained (announcement)"
- Previous message: James Giles: "Re: Function PRESENT and logical combinations"
- In reply to: Janne Blomqvist: "Re: Function PRESENT and logical combinations"
- Next in thread: glen herrmannsfeldt: "Re: Function PRESENT and logical combinations"
- Reply: glen herrmannsfeldt: "Re: Function PRESENT and logical combinations"
- Reply: James Giles: "Re: Function PRESENT and logical combinations"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|