Phillip Helbig wrote:
>This isn't backward-compatible, as A*(B+C) forces evaluation now; you
>need a NEW notation for a new feature.
and Kurt Hirchert wrote:
! That's why it was proposed to add a second evaluation mode rather than
! changing the behavior of the existing mode. The new mode would reflect
! what people usually meant by parentheses, while the old one would be
! retained for those people who actually depended on the evaluation order
! guarantees it provided.
A reasonable place to specify a different mode is on the introductory
statement of a construct. If specifying a new mode is the only thing you
want to do, it seems obfuscatory to be required to use a construct that
has another functionality, e.g. IF (.true.) or DO i=1,1.
Let me propose a trial balloon consisting of three things.
(1) Augment the syntax for the statements that introduce block constructs
to allow specification of modes that apply only within the blocks. This
could be a prefix, a suffix, or buried within:
a. with(new_mode) if ( foo ) then
b. if, new_mode [::] ( foo ) then
c. if ( foo ) then :: new_mode
etc.
(2) Allow a new block construct that serves two purposes:
a. A place to put mode declarations
b. A place to put a construct label to which EXIT could refer
(3) In addition to specifying what parentheses do w.r.t. grouping or forcing
order of evaluation, allow specifying the kind of intermediate results of
real type.
At present, it is the kind of the most precise operand. Sometimes this
isn't enough. For details see "Why JAVA floating point hurts everybody
all the time" by W. Kahan at http://http.cs.berkeley.edu/~wkahan/JAVAhurt.pdf.
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|