forums.silverfrost.com

KL · Joined: 16 Nov 2009 Posts: 155

Is it correct that in Fortran 9x free source form, an operator may not contain embedded blanks? The following code gives an example where FTN95 accepts such blanks:

Wilfried Linder · Posted: Wed Jan 19, 2011 11:13 am Post subject:

Klaus,

as far as I know, it is recommended to use ">" instead of ".gt." and so on in Fortran95 code, and it seems to be the actual standard now. I found a short text with some advise for the portability of Fortran code:
click

Hope that this can help a little.

Regards - Wilfried

LitusSaxonicum · Posted: Wed Jan 19, 2011 3:20 pm Post subject:

Wilfried,

I've been a believer in compiling with as many compilers as I can get my hands on, but this is a huge luxury only available in a few environments such as the PC. For most of history, you were stuck with the compiler that came with your hardware, and to even get the code to work elsewhere you may have needed to translate even the punched cards, and use system-specific commands.

I had a look at your reference: it rules out all legacy code, obviously. Also rules out Clearwin+. Makes it pretty difficult to use many forms of graphics, and most non-trivial user interfaces. Fair enough, for some programs, portability is mission-critical. For others, the user-interface is all. In the latter case, there isn't much choice but to contravene most of the rules in that guide! (For me, the choice is FTN95 or give up).

Most of the fixes reported in any compiler's history of bug fixes (e.g. FTN95, but it isn't alone) relate to 90/95/2003 features - and therefore by definition, the newer language features cannot form part of a "Safer Subset" (viz. the writings of Les Hatton).

It has never been clear to me how KIND was more reliable than "type*n" e.g. REAL*8 (in the real world, and no pun on the word real intended).

Eddie

KL · Joined: 16 Nov 2009 Posts: 155

Wilfried,

thanks for the information. I had already considered such a possibility, but I have never seen such a form as the only standard form. It also seems to me that your reference is more a recommendation (...it is encouraged to use...) rather than a rule.

Klaus

PaulLaidler · Posted: Wed Jan 19, 2011 4:34 pm Post subject:

I have looked at the standard and it seems that this is not clearly defined.

The compiler preprocesses fixed format code by removing spaces except in string quotes. This is effectively Fortran 77 so spaces are accepted within intrinsic operators.

In free format code spaces become significant and the standard intrinsics are defined in the Fortran standard without embedded spaces. Also user-defined operators must only contain letters.

I guess it was a reasonable assumption for FTN95 to not allow spaces in free format intrinsic operators but other compilers may be more flexible at this point.

I don't know off hand how much work would be involved in allowing this as a sort of extension.

KL · Joined: 16 Nov 2009 Posts: 155

Paul, may be that I misunderstand you. In my opinion it is just the opposite: FTN95 accepts blanks in expressions like . eq. (please see my example code), which in my opinion it should better not.

Klaus

PaulLaidler · Posted: Wed Jan 19, 2011 8:16 pm Post subject:

OK I see the difference. Your examples have leading or trailing spaces. I was putting spaces between the letters.

So in fixed format code you can have spaces anywhere between the dots whilst in free format code you can only have leading or trailing spaces between the dots.

As before, I guess that this could be changed except that there might just be someone out there whose code I would break by making the change.

KL · Joined: 16 Nov 2009 Posts: 155

Paul,

I have no idea what the standard exactly says. I understood from all what I have read, that an operator or separator such as "(/" or "/)" or name or number may not contain embedded blanks. In my opinion it is therefore not consistent to allow embedded trailing blanks after the dot or leading blanks before the dot in an operator like ".and." This should lead to an error message or at least to a warning.

For our application I have written a conversion program that removes such blanks, because they lead to error messages in other compilers.

Best regards,

Klaus

IanLambley · Joined: 17 Dec 2006 Posts: 506 Location: Sunderland

The standard (ISO/IEC 1539-1 2010) says:

LitusSaxonicum · Posted: Thu Jan 20, 2011 5:51 pm Post subject:

I suppose it all boils down to whether .AND. is a single "lexical token" or 3 ("." , "AND" and "."). I would have put my money on it being just one.

Apart from embedded blanks not working with other compilers, what potential problems could occur by permitting the embedded blanks in this context, e.g. treating .AND. as 3 lexical tokens? Of course, if it is (they are) 3, then blanks are surely compulsory in free format!

I always hated these so-called logical operators. Bring back the Arithmetic IF !!! :wink:

Eddie

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Can this not be answered by seeing what the definition of a "Token" is. If a token is not allowed to be "." then it would follow that ".gt." cannot be three tokens.

Personally I prefer >, >= etc (but why do we have to suffer the dreadful /= when != would have been more natural.)

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Can this not be answered by seeing what the definition of a "Token" is. If a token is not allowed to be "." then it would follow that ".gt." cannot be three tokens.

Personally I prefer >, >= etc (but why do we have to suffer the dreadful /= when != would have been more natural.)

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Can this not be answered by seeing what the definition of a "Token" is. If a token is not allowed to be "." then it would follow that ".gt." cannot be three tokens.

Personally I prefer >, >= etc (but why do we have to suffer the dreadful /= when != would have been more natural.)

davidb · Joined: 17 Jul 2009 Posts: 560 Location: UK

Oops, there is some issue with posting I see. Apologies for the multiple post.

KL · Joined: 16 Nov 2009 Posts: 155

Paul,

the discussion shows that this issue needs to be clarified. Metcalf defines a token as a sequence of alphanumeric or special characters and refers to a table which defines the tokens �.eq.�, �.ne.� etc. For me this indicates that the dot in these expressions is part of the token and is not be considered as separator or something else.

The free format of FTN95 not only allows having trailing blanks after the dot at the begin and leading blanks before the dot at the end for operational operators, but also for logical operators and for .true. and .false. as well. FTN95 does not give an error message for a statement such as

If ( (. not . x) . and . y ) z = . true .

Of course this is extremely bad programming. Further the colorization in most editors would not mark anything in this line.

Nevertheless, if �as you say- this is not clearly defined by the standard, I would suggest to make this an issue for the standard committee. We do not increase the portability of free format Fortran 9x if such simple definitions stay unclear.

Klaus