Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.


Valued Contributor III

Just out of interest, why did Fortran not introduce symbols for .not. etc. as for .eq. 

I prefer the .not. as they are easier remember.  

0 Kudos
4 Replies
Black Belt

The short answer is that the committee is loathe to "burn" another character that might need to be used for something else in the future. The comparison operators all use characters already in the Fortran character set.  It DOES happen, and there was a battle over the addition of [] as an alternative to (//) in array constructors (from Sun, which had used [] for intervals.)  Would you also want symbols for .AND., .OR., .EQV. and .NEQV.?  There is a feature for F202X that currently uses @ , but many are unhappy about it.

Valued Contributor III

No I like it the way it is, it is always a pain to look up the && and remember in language XYZ what it means.  

Makes it easy to read.  

I have always used .eq.  etc.. and I was bemused the other day when I looked at some old code and saw them using == etc. and thought I have to get out of the 1970s.  


0 Kudos
Honored Contributor II

The world is a varied and interesting place! I always use == and  /=  etc and hate .EQ..  Additionally .OR. is far too many characters as for readability and needs a space either side to that is 6 characters! Anything more than ( A .OR. B) for me becomes ( ANY([ A, B, C, D]) )  much more to the point and more likely to be on one line of code!

0 Kudos
Valued Contributor III

I understand your comment. As you said we are all different.  

I was looking at inquire this morning, and I was so glad I could just out my MS Fortran V5 manual from 1991 and find a sample, 

then I looked in the latest oneapi manual and aside from c to ! it is identical.  MS wrote and published good manuals. 

0 Kudos