forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

Curiocities
Goto page Previous  1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General
View previous topic :: View next topic  
Author Message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Mar 30, 2015 7:47 am    Post subject: Reply with quote

Dan,

Still on the tabs; It is one problem to have Plato (or other IDE's) interpreting the tabs, but what does FTN95 do with tabs, especially in .for files ? After all, it is what the compiler does that is important.

Ban tabs !! (or make their interpretation standard)

John
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Mar 30, 2015 8:17 am    Post subject: Reply with quote

FTN95 replaces a tab character by 8 spaces and this does not depend on the column position. FTN77 will be the same.

Plato and VS can be configured for different tab sizes and to replace tabs by spaces as they are typed. In this case the tabs are expanded depending on the column position. In Plato you can have different settings for fixed and for free format files. See the Options dialog on the Tools menu.

As far as I can remember configurable tabs have been available in Plato since version 3 (i.e. a long time ago).

Plato also has a command to replace all existing tabs in a file by spaces. By default this command does not have an associated accelerator key so you will need to open the Option dialog box, select Environment then Keyboard and look for Edit.ReplaceTabs. You can then choose your own accelerator key for this. I have it set to Ctrl+R.

I will make a note of John's request for tabs to be rejected via an FTN95 command line option.
Back to top
View user's profile Send private message AIM Address
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Mar 30, 2015 10:25 am    Post subject: Reply with quote

Now that Paul has clarified that FTN95 treats each tab character in input source as eight spaces, Dan's problem becomes well-defined. Note that the replacement is not done if the tab character is part of a string constant.

If Dan chooses to keep tabs in his source files, it becomes Dan's responsibility to ensure that each source line, after replacing each tab with eight spaces, is

(i) valid Fortran source that does not cross the right boundary (beyond column 72 in fixed form and 132 in free form), and

(ii) the semantics of the source after tabs are converted are the same as those that Dan intended.

Statements that are long and are spread over several continued lines may need correction if they contain tabs. Since such statements are not likely to be pleasing in appearance anyway, it may be best not to use tabs in continued lines.

It would be easy and worthwhile to write a utility program that scans Fortran source files and flags any lines that cross the right margin after substituting for tabs that are not within strings.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Mar 30, 2015 10:53 am    Post subject: Reply with quote

Intel ifort defines 3 source forms; fixed, free and tab.
The tab form appears to be an adaptation of the fixed form and describes a special interpretation of the tab character in columns 1 to 5 then subsequent tabs appear to be associated with columns 9, 18, 27 etc, using an 8 space field. (can't guarantee I have this correct as I have never used this approach.)

I have found when receiving tab form source, other IDE's and compilers do not recognise this source form and so it must have limited portability.

In the old Lahey F95 compiler I have, I can't find any reference to the use of tab characters in source. It may treat it as any number of spaces.
If tabs were interpreted as 3 spaces, I probably would have adopted it for DO loop indentation many years ago, but 8 spaces is too much.
They simply cause confusion when skipping between IDE's, so my old line editor that I used in 80's removes them.

I am certainly not recommending FTN95 adopts this form, which I can't find in any Fortran standard.

John
Back to top
View user's profile Send private message
IanLambley



Joined: 17 Dec 2006
Posts: 490
Location: Sunderland

PostPosted: Mon Mar 30, 2015 12:44 pm    Post subject: Reply with quote

Tabs are dangerous - I never use them. I nearly always use fixed format due to my advancing age and use the following scheme:
1. Statement and format numbers have 4 digits: type <space> and the number then <space> and carry on with the line
2. Continuation lines: 5*<space> <apersand>
3. Indentation +-2 spaces per level.
4. Normal lines: 6*<space> then the indentation then the line.

I posted a fix for tabbed files some years ago, see:
http://forums.silverfrost.com/viewtopic.php?t=785&highlight=untab
Ian
Back to top
View user's profile Send private message Send e-mail
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Mar 30, 2015 12:56 pm    Post subject: Reply with quote

Mecej4, thanks for the clarification. So, if you have IMPLICIT NONE (implicitly or explicitly) then all your function names that are provided in separate source files need to have their type declared somehow? How do you know what is in scope until linking if you have separately compiled files? I'm too old a dog for this new trick.

Dan, TABs were always an extension. On IBM model 26 and 29 card punches, you could press the TAB key, but it always gave you spaces by advancing the card in the punch.

My recollection is that Hollerith cards used a 6-bit code, thus excluding many control characters in the resulting 64-character set. The TAB character wasn't part of the character set. We Brits often used 8-hole punched tape, giving us a 7-bit code allowing 128 characters (the 8th hole was used for a parity check as the punches weren't reliable). This opened up a whole range of extra characters, including control characters, and the adoption of terminal-based systems allowed 256-character codes with even more.

Thus, TAB is original sin, no matter how useful it has been.

Eddie
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Mar 30, 2015 1:13 pm    Post subject: Re: Reply with quote

Eddie wrote:
So, if you have IMPLICIT NONE (implicitly or explicitly) then all your function names that are provided in separate source files need to have their type declared somehow? How do you know what is in scope until linking if you have separately compiled files?

The IMPLICIT statement was added in Fortran-77. Most F77 compilers also supported the MIL-STD-1753 extensions, which included IMPLICIT NONE.

The scope of variables in F77 is the program unit (main program, subroutine, function, block data). This is also true of Fortran 90 and later versions if we do not use modules. Whether the program units are in the same or different files does not matter since, unlike in C, variables are declared inside a program unit and do not have file scope.

Here is an example. Try it as is and then try it after commenting out the type declaration of the function SQR in the main program.
Code:

program ximp
   implicit none
   real :: x,y,sqr
!
   x=2.0
   y=sqr(x)
   write(*,*)x,y
end program ximp
!
function sqr(x)
   implicit none
   real :: x,sqr
!
   sqr=x*x
   return
end function

Eddie wrote:
On IBM model 26 and 29 card punches, you could press the TAB key, but it always gave you spaces by advancing the card in the punch.
Indeed. You could punch a tab control card with holes in the columns where you wanted tab stops, mount that card on the drum in the keypunch machine (see http://www.columbia.edu/cu/computinghistory/029-drum.jpg ), and from then on each press of the SKIP (=tab) key would advance the punch head to the next tab stop. We used to carry a set of these curled-up cards, one for Fortran, another for Algol, etc. With the Fortran tabs card mounted, after a new card was fed you would press SKIP, and the punch head would then be in column-7 -- a lot quicker than typing six blanks. When you wanted something in columns 1-6, you typed that in instead of pressing SKIP.

Last edited by mecej4 on Tue Mar 31, 2015 1:51 am; edited 2 times in total
Back to top
View user's profile Send private message
LitusSaxonicum



Joined: 23 Aug 2005
Posts: 2388
Location: Yateley, Hants, UK

PostPosted: Mon Mar 30, 2015 1:54 pm    Post subject: Reply with quote

OK, I see how it reports the error. An education for me.

I can't help but feel that with every passing iteration, Fortran looks more like Algol, but never quite gets there.

Thanks for the reminder about how the tabs were set, I'd forgotten. I preferred the modernist look of the 029 to the Art Deco Cinema look of the 026, but I expect that the guts were the same.

Eddie
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Mar 30, 2015 4:46 pm    Post subject: Reply with quote

The reason for the fatal is clearly as I said before, because the line has 73 characters (assuming the tablength is interpretted as that number of spaces), as Dan says , nothing to do with tabs (except that maybe the tabs being 8chars not 6 are throwing it just over the 73 chars - maybe that makes it a bug in FTN95 for assuming arbitrarily 8 chars for a tab LOL :=), seriously, wouldn't 6 be better when it occurs at the beginning of a line, why 8 ? )

So, what about the 'meaning' of the message, which I think is Dan's point.

Well ....
The second line is then presumeably still treated as a continuation but the operand ('/') is missing so there is just a variable in brackets at the end of the line, following directly from the last parentheses on the previous over-long line
i.e. is the compiler seeing this:-

Code:
Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)    (RELABexSUM(IZSp1,iii)+1.e-7)


OR, if the spaces at beginning of continuation line are ignored by the compiler then:

Code:
Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)(RELABexSUM(IZSp1,iii)+1.e-7)


I googled for the error message and found an occurence on the Silverfrodst Forum ! .... here ....

http://forums.silverfrost.com/viewtopic.php?p=9325&sid=1575c7d7cefc5e99730e9e58ad4dc84d

... it's of little direct help though as in that case it was in combination with a clear mis-definition of an array.
However it could indicate it may be related to the array defn. in some way (maybe the ':' relates to its dimensions ?) ... except that it doesn't know it's an array,
(Yes Dan I spotted the declaration was in the directly posted code as you said above).
OR, because it's F77 it's mixing up the variables (F77 character names limited to 6 characters, maybe RELABexSUM is same as RELABex (= RELABe) to the compiler ? - unless there's an extension within Silverfrost/SalfordF77 which allows more ???. I couldn't find the documentation on that )

Also note that the error is error no. 612 (which can be obtained by using either ftn95 -e or ftn95 /ERROR_NUM for compile)
the error message also can appear with different numbers (presumeably because it occurs for more than one reason).

Interestingly also, if you remove the brackets on the continuation line the error message doesn't appear ! (a different one though, so don't get too excited). Is that a clue ?

I guess the key is, obviously: 'what does the ':' refer to ?'
Could be related to the dimensions of the array (as evidenced by it's appearance on the other forum post as quoted above) .. .or ....

Whilst searching I also came across this:-

ref. http://www.starlink.rl.ac.uk/docs/sun7.htx/node9.html

" The Fortran Maximum Record Length

The GENERIC utility assumes it is dealing with Fortran 77 source code which cannot go beyond column 72. If the substitution of a token results in a line becoming longer than 72 characters, it will be broken automatically at column 72 and continued on the next line, using a ``:'' continuation character in column 6 of the next line.

It is recommended that source lines in generic routines be kept well below 72 characters in length to prevent this from happening. "

Now, of course that is from the internal workings of a program called 'GENERIC' and may or may not be relevant.
I don't know if this is what happens in FORTRAN itself or not, I couldn't find any documentation about what happens exactly in a fortran compiler when the length exceeds 72 chars, does it also treat the next line as a continuation and replace the * with a ':' ???

All worth chewing over and contemplating.

-P.S. -
Oh, and whilst I accept that logically a non-existence of a function called 'RELABexSUM' would be 'trapped' at link time, it would make sense to flag it as a WARNING at compile time with message such as:
' WARNING message : RELABexSUM not declared as a variable an
Back to top
View user's profile Send private message
John-Silver



Joined: 30 Jul 2013
Posts: 1520
Location: Aerospace Valley

PostPosted: Mon Mar 30, 2015 5:05 pm    Post subject: Reply with quote

.... maybe the simplest way of finding out of course is by Paul getting someone to search through the source code to find out exactly what reasons there are for the issuing of that message ????
Should be simple Wink
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Mon Mar 30, 2015 5:22 pm    Post subject: Reply with quote

The Generic utility that John Silver referred to has no bearing on the FTN95 error message regarding the colon. To see that, change the code of the loop to the following:
Code:
      DO  i = 1, NUMBlevsZ (izs)
        C_Sum = 0
        Do  j = 1, NUMBlevsZ (izs+1)
        C_Sum = C_Sum + Ct_Hull(j,i,IZSp1) (RELAB(IZSp1,iii)+1e-7)
        enddo
      enddo
I have simplified the expression, and shortened the variable names, so no continuation line is needed and there is no line that is longer than 72 characters. However, as in Dan's example code, wherein tab expansion moved the '/' operator to a position beyond column 72, I have left out the '/' operator that should have been present between the adjacent parentheses.

The compiler again gives the error message involving the mysterious colon. This is simply another instance of a compiler not quite giving a clear diagnosis when the input code is in error, and I do not think that we should complain loudly in such instances.
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Mon Mar 30, 2015 11:44 pm    Post subject: Reply with quote

Dan,
I downloaded your file defect.for and listed it with my utility to expose control characters. It lists as:
Code:
[31]         integer NUMBlevsZ (100)<CR><LF>
[36]         real*4 RELABex (100,100,100)<CR><LF>
[36]         real*4 Ct_Hull (100,100,100)<CR><LF>
[ 1]  <CR><LF>
[27] <HT>DO  i = 1, NUMBlevsZ (izs)<CR><LF>
[16]  <HT>  Ctbr_Sum = 0<CR><LF>
[31] <HT>  Do  j = 1, NUMBlevsZ (izs+1)<CR><LF>
[66] <HT>  Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)/<CR><LF>
[39]      *    (RELABexSUM(IZSp1,iii)+1.e-7)<CR><LF>
[ 8] <HT>  enddo<CR><LF>
[ 6] <HT>enddo<CR><LF>
[ 4] <HT>end

If I replace all <HT> with 8 spaces, I get
Code:
        integer NUMBlevsZ (100)
        real*4 RELABex (100,100,100)
        real*4 Ct_Hull (100,100,100)
 
        DO  i = 1, NUMBlevsZ (izs)
           Ctbr_Sum = 0
          Do  j = 1, NUMBlevsZ (izs+1)
          Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)/
     *    (RELABexSUM(IZSp1,iii)+1.e-7)
          enddo
        enddo
        end

Note that the / on line 8 is in column 73 so the expanded line 8 really looks like
Code:
        Ctbr_Sum = Ctbr_Sum + RELABex(j,IZSp1,III)* Ct_Hull(j,i,IZSp1)
     *    (RELABexSUM(IZSp1,iii)+1.e-7)

Including compile option /WIDE removes the error message, confirming the interpretation of <HT> replacement.
I tried the compile option /no_truncate but the colon error was again reported.

The devilry is in the "hidden" code, those dastardly tabs

John
Back to top
View user's profile Send private message
JohnCampbell



Joined: 16 Feb 2006
Posts: 2554
Location: Sydney

PostPosted: Tue Mar 31, 2015 12:51 am    Post subject: Reply with quote

Eddie,

From memory the 029 was much preferred to the 026, as it had more capabilities. I just can't remember what those capabilities were !

Just about every day, I would catch the bus to uni, go to the physics building, pick up the overnight run, go to the card punch room in the basement and look to see if there were any 029 desks free. It almost never happened ! Always too late. Never a thought about indenting do loops in those days, just hoping there were no typing errors, or another day lost.

Back to tabs; there are two possible interpretations. FTN95 appears to replace the tab with 8 spaces, while other interpretations move the next character to the size 8 grid or what ever the spacing is.
I just tried notepad, which has the grid approach, but the column count in the status bar does not agree.

Further, I opened Dan's defect.for in PLATO and it does not display the tabs in a way that FTN95 interprets. This is a problem ?

John
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Mar 31, 2015 10:39 am    Post subject: Reply with quote

You are right, guys, this / is in column 73. But how this happened? I checked that twice and saw it at reliably below of that (and i always care about that limit with the eagle eye) ? Don't understand that...Still a damn devilry. I feel bad like aging Dersu Uzala when he for first time missed his bullet into Siberian tiger.
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1885

PostPosted: Tue Mar 31, 2015 11:53 am    Post subject: Reply with quote

DanRRight wrote:
You are right, guys, this / is in column 73. But how this happened? I checked that twice and saw it at reliably below of that (and i always care about that limit with the eagle eye) ?
That depends on how you did the checking. If you used a text editor or used the TYPE <filename> at the console, the transformation of tabs done by the editor or CMD would have probably been different from the transformation that FTN95 applies, so your eagle eye could have been viewing the code through grandma's glasses.

Since your code-base is large, you need to use a more reliable system to check your source code than relying upon mere visual checking of small samples of the code. Obtaining/building filters to do the checking is quite easy, but you need to summon the will and take the initiative.

I think that the design decision to have FTN95 treat a tab as equivalent to eight spaces is regrettable. It would have been better if FTN95 rejected tabs completely instead of applying an interpretation that is different from the interpretations given by other Fortran compilers that allow tabs in source input, and different from the well-known response of typewriters, teletypes and line printers to tab keys/characters. The FTN95 interpretation of tabs is not even consistent with Plato's treatment of tabs, and it is impossible to check by viewing in Plato whether a source file with tabs goes beyond column 72/132.
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> General All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4  Next
Page 2 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group