Well, people should not be using FORTRAN - the form of the language before 1990. They should use Fortran instead. The applications you listed all come under the umbrella of “scientific computation”, though they are really numerical computation. Fortran has been accused of being a domain-specific language for HPC, which has generally become the reality. Especially now that Fortran is the only language you listed that is natively SPMD-parallel. Languages like C/C++ were designed for writing operating systems and similar code. Use the right tool for the job at hand…
4 Likes
I don’t really see the need for this new syntax at all, as the well-established merge intrinsic function surely does the same thing. instead of
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
you can simply use
y = merge(a(i), -Huge(y), i>=1 .and. i <= size(a))
What is wrong with that? I use this sort of thing quite often in my code.
You probably shouldn’t! The issue with the MERGE intrinsic is that all the arguments are evaluated. In conditional expressions, only some legs (subexpression) are evaluated.
But if we are going down that route rather more of Fortran should be altered.
In the previous example both the (i >= 1) and the (i <= size(a)) sub-expressions will both be evaluated as the Fortran Standards going way back have required that, but in principle if i is less than 1 the second sub-expression doesn’t need to be evaluated at all. That could be done if Fortran had some more operators to supplement the simple .and. which has sometimes been suggested.
We’ve always had “might not be evaluated”. Now we have “must not be evaluated”.
The evaluation of both comparison expressions in “( i>=1 .And. i<=Size(a)” appears so trivial on modern systems in conjunction with the language semantics with arrays and the overall statement looks so compact, that is likely the reason the above proposal (paper) that got accepted (passed) showed it.
But otherwise when coders are concerned with needless or risky evaluation of expressions, they can always take the traditional route - no one is taking that away:
blk: block
if ( i >= 1 ) then
if ( i <= size(a) ) then
y = a(i) ; exit blk
end if
end if
y = -huge(y)
end block blk
Or, see if this in-the-works conditional expression facility can help.
The committee had considered the .andthen. and .orelse. short-circuit operators but these failed to receive adequate support from the brain trust!
1 Like
Historically, Fortran has favoured clarity over conciseness. However, ubiquity of C and its derivatives has unquestionably tilted the scales for syntax towards a terse format utilizing all sorts of symbols on a keyboard, which is not difficult to learn, but is anyway very far from pseudocode. Had it not been the popularity of Python, keywords based syntaxes would have become endangered by now.
As for the conditional expression, the ship has sailed. I am standing at the port with you, though. So is @certik, I think. Let us make peace with it now. Nobody is forcing us to use ?. Those who dislike it can continue to practice the extended version.
2 Likes
What precedence rules apply if the two alternatives separated by ‘:’ are of type logical?
A vote for keyword here. Clear, concise, and a low barrier to entry for code maintenance.
1 Like
Welcome to the forum. Note that the committee has voted to adopt syntax such as
y = ( i>=1 .And. i<=Size(a) ? a(i) : -Huge(y) )
2 Likes
Are the parentheses required?
Great question, others may have the answer ready - but I’ll look into it also and post here later, if nothing else for an independent verification.
1 Like
If I recall correctly, I believe the parentheses are required in order to clearly disambiguate. I.e.
x = y .and. (z .or. w ? u : v) .or. t
or slightly less contrived
a = b + (c > 0 ? c : d) - e
Of course operator precedence could have been clearly defined, but I think there might be even more corner cases and it was easiest and cleanest to just require the parentheses always.
2 Likes
To elaborate further, is this
Case 1:
logical :: y
y = i>=1 .and. i<=Size(a) ? .false. : .true.
equivalent to,
Case 2:
y = (i>=1 .and. i<=Size(a) ? .false. : .true.)
in @Beliavsky’s syntax, or to
Case 3:
y = (i>=1 .and. i<=Size(a)) ? .false. : .true.
or to
Case 4:
y = i>=1 .and. (i<=Size(a) ? .false. : .true.)
The fundamental question is: Are there any precedence rules for ? over the logical operators? I think this is similar to @mecej4’s question in the above. In any case, it feels like the parentheses in @Beliavsky’s example should not be really needed. Thanks for clarifications from knowledgeable people on the matter.
1 Like
No, ? is NOT an operator in the current definition. Conditional expressions are a primary, like a literal constant. (See Doctor Fortran in “Order! Order!” - Doctor Fortran (stevelionel.com) for some discussion of primaries and expressions.) The ? is just part of the syntax (as are the parentheses.)
1 Like
Thanks. So I assume missing the parentheses is a syntax error.
Correct.
1 Like