Uniary operator following arithmetic operator

[hiroshi-murakami]

! (ifort version 15.0.0 or earier)
!　 I think it is a bad idea to extend the grammer of the arithmetic expression
! in Fortran langurage as the followings.
! Such functionality might look convenient at first, however it would enhance

!possibilities to make the compiler to silently ignore  possible human-errors

! such as mis-types especially in lengthy expressions.

ifort accepts the source code below without errors nor warnings.

---------------------------

program to_be_avoided
implicit none
real a, b, c, d, e, f, g, x, y, z, w
   a = --3.0
   b = ++3.0
   c = -+3.0
   d = +-3.0
   e = 2.0 +-3.0
   f = 2.0 *- 3.0
   g = 2.0 *+ 3.0
   x = 2.0 *- 3.0
   y = 2.0 /- 3.0
   z = 2.0 +-+ 3.0
   w = 2.0 +-+----- 3.0
   !----
   a =  2.0 ++ a / x
   b = --y
   c = +-w
   d = y *- x
   e = z /+-a
   f = -- y ++ a /- x
   g = -- y ++ a / -----x
   x = -a **-x
   y = -+a **--x
   z = --a **+ x ** y
   w = sin(++2.0) -- sin(x--y)
! integer expressions as well (omitted).
end program to_be_avoided
---------

You can also compare with GNU's gfortran or other compilers.

[Steven_L_Intel1]

This is a decades-old extension in our compiler. If you enable standards checking, you'll get a warning. Different compilers vary in which extensions they support.

[jimdempseyatthecove]

The above has historically been part of the FORTRAN (now Fortran) specification.

This said, it might be nice to have an option such as /warn:multipleunaryoperations

You might perform an internet search for a Fortran Lint program that could be used to catch such cases.

If not, AWK or Perl or grep might be able to do this for you.

For any of us ancient programmers that remember TECO

< :n^E[+,-]^E#^ES^E[+.-]$; V >

The above loops, conditional search for + or - character, followed by zero or more space or tab, followed by + or -. If found, display the line and continue loop. If not found, exit the loop.

You should be able to do the same functional thing in awk, pearl or grep.

Jim Dempsey

[TimP]

A few of those examples historically gave different results with various compilers which supported them under default options. Thus the decision of gfortran to reject them and the importance of setting Ifort standard check. If there is a reason for using such cases parentheses may be inserted to comply with standard, but assume protect_parens may be required for unambiguous interpretation.