Not Clear diagnostics

That link was fun but the fact i spent today one hour swearing was definitely not. Same error - spurious symbol in the name of array subscripts and the FTN95 again tricked me into its typical anti-user snobism about 'automatic arrays' or their not 'explicit shape' because as we now know the developers do not use their own Fortran compiler heavily and the users do not report any suggestions for improvements

0531) COMMON /ExpD_/ CaptionExp1(nMaxFiles_Exp),&
0532) &  CaptionExp1Displ, &
0533) &  Xg_Exp(idimExpDat0,nMaxFiles_Exp), &
0534) &  Yg_Exp(idimExpDatO,nMaxFiles_Exp)

*** Error 477: The DIMENSION specification for variable YG_EXP is not an 
    explicit shape
*** Error 897: YG_EXP cannot be used as an automatic array as it is in a 
    COMMON block

Fine, let this wording stays but adding 'Did you possibly forget to set array subscript idimExpDatO?' would help better like FTN95 sometimes doing with other cases

You left out the declarations of the types of the variables in the common block and the types and attributes of the array extents such as nMaxFiles_Exp. Those quantities would usually be integers with the parameter attribute, or dummy arguments.

Without that information, I am unable to comment on what the compiler said. Usually, when a compiler gives many messages that do not make sense, it is also true that the code that you gave to the compiler does not make sense to the compiler, at least by itself.

I tried the compiler on these lines from The Tale of Two Cities

It was the best of times, it was the worst of times
It was the age of wisdom, it was the age of foolishness
It was the epoch of belief, it was the epoch of incredulity

and it said

[FTN95/Win32 Ver. 8.51.0 Copyright (c) Silverfrost Ltd 1993-2019]
0001) It was the best of times, it was the worst of times
*** Statement not recognised
0002) It was the age of wisdom, it was the age of foolishness
*** Statement not recognised
0003) It was the epoch of belief, it was the epoch of incredulity
*** Statement not recognised
*** Missing END statement
    4 ERRORS  [<main program> FTN95 v8.51.0]
*** Compilation failed

What would you have expected from the compiler in this case?

Dan,

From what you have posted, I would expect that idimExpDat0 and nMaxFiles_Exp are not integer parameters. If the compiler is issuing so many error/warnings then I doubt if the definition of these parameters is available. Also, why is the compiler suggesting YG_EXP is an automatic array ? must be in code not listed.

A safe approach is to define the COMMON /ExpD_/ in an include file, where the array dimensions are clearly provided as parameters.

At a minimum, you should be using implicit none or /IMplicit_none, rather than complain about the compiler messages.

Mecej4,

On the grounds that the compiler is expected to have mind-reading capabilities, perhaps it should have said that a continuation was required between lines 1 and 2, and again between lines 2 and 3; that lines 2 and 3 shouldn't have been capitalised, commas were missing, and so was the rest of the sentence!

Then again, it perhaps should have known the name of the Author, and remarked that the bulk of the program was missing ...

And on the subject of The Tale, I see that dear old Charles (after all, England is so small in the eyes of our transatlantic cousins that we all know each other, and are on first name terms) is excessively formal, as I know Mrs Southcott (a few lines on) as Joanna, although I have never examined her famed box (I'm not a Bishop).

And indeed, having successfully compiled and run, perhaps Clearwin+ in the embrace of both Windows and FTN95, should, instead of a FORTRAN STOP, present a window, in which one might read:

“It is a far, far better thing that I do, than I have ever done; it is a far, far better rest that I go to than I have ever known.”

... with a button marked 'OK'.

Eddie

Eddie, make the button say 'OK, or Not OK?', because that is more often what is meant. It is not your agreement with the conclusion 'OK' that is sought, just your permission to terminate the misbehaving program.

As i wrote several times that 21 century compilers have to have the next level of suggestions besides the ultrashort ones they give today. They have to start learning from the experience compiling this code for 1000000 times in 40 years.

People will not notice, like my example just showed above that idimExpDatO and idimExpDat0 are not the same but compiler will distinguish them immediately.

Besides this is the common block and compiler can get additional info from same common block in other place and in this case tell almost for sure that the index idimExpDatO is not defined because of typo O instead of 0. So it will guess more precisely. If it will be wrong - like with mecej4 funny extreme examples, i will learn from that too and do not judge it too strongly. You are laughing, but eventually in the lifetime of already current generation the artificial intelligence will laugh on us humans even more.

In the case all you missed i already saw first indications of implementation of what i am saying, so it is not new. I saw that FTN95 in some cases tells 'Have you forgot to ... ?' or something like that. I want this to continue introducing the key with different levels of /verbose_compilation. Compilers should babysit their users.

As to John's 'implicit none' - thank you, but no, i will not use it, i already responded on that. I will find the error like above eventually and will find it even much faster in the future if compiler will help me more. But i will not find the subtle rounding error, or wrong indexing error or tricky accuracy error in a lifetime with 'implicit none' if i will think that some variable idimDoSomething is integer but it actually is real or vice versa. Experience shows that I have no time, and no one else has it, to search the long list of declarations of variables which was grown to the size of phonebook of a decent size village - are these variables real or integer

Dan,

Having some experience with modest AI approaches, there is no API wrapper to include '/verbose_compilation' as part of the clearwin+ approach for FTN95 to include new AI capability. Microsoft does not appear to have this in their library and as to the friendliness of the MSDN, I don't think they have a good history.

It is interesting to suggest that the compiler should learn from our history of use. Not sure how Paul would add this to the wish list.

That said, you do raise some interesting ideas for how compilers should evolve.

John

Mecej4,

There's no point in taking the frivolous seriously. If one did, then 'OK' is not a good response, as it so often is not in a real Window, and the guidance from Microsoft tells us to use an action word. In the interests of brevity, I didn't list all the options, including 'Post a note on the forum', with options to select 'Use language intended to provoke', 'Adduce satanic involvement', and so on.

In a more serious vein, Dan, your variable ending in 0 or O is something that one should avoid, because it is well-known that these two characters are often typed mistakenly - not, I might add, because they look the same, but because they are close together on the keyboard. The error is not detected because they look the same. The answer is usually to use base 1 not base 0, although with the wrong font I or l might look like 1, but at least those characters are well-separated on the keyboard. Also, 'camel case' does not separate letters and numerals as well as the underscore does, so it is much more likely that you catch the problem yourself with idimExpDat_0 than with idimExpDat0. Just a hint.

My other finger-trouble is with comma and full stop, where I might not pick up the problem visually. Your experience may differ.

Eddie

Yes, Eddie, i am trying to avoid some combinations (i afraid l the most, taking always L which often does not look pretty) , but unfortunately logic of the human and mathematical language sometimes requires to take zeroes and l, 1, i etc.

I remember ones in the beginning of 80th i in seconds helped to fix O-0 problem from one desperate guy who was searching for the bug for several days! And now FTN95 took the hell out of me for almost one hour, imagine how i was furious, thinking i am kind of almost a pro 😦

Here is another example of not perfect diagnostics in this demo

Do i=1,111
  if(i.eq.2) then
  a=i
end do
end

0004) end do
*** Nesting error - this statement belongs to the DO construct at line 1, but 
    is embedded in the block IF construct starting at line 2
    1 ERROR  [<main program> FTN95 v8.51.0]
*** Compilation failed

Instead of telling that possibly ENDIF is missing as most probable error the FTN95 starts showing its Cambridge and finishing school education talking about DO loop constructs which is by the way completely fine. Assuming opposite (that by the enddo user meant endif) means double error which is less probable

And here i may misinterpret English possibly:

text64 = trim(SaveDirName

*** Unpaired right bracket(s)

Why this is called 'Unpaired right bracket' while it is unpaired left bracket? It is 'missing right bracket' but if unpaired then unpaired is left one

Ah yes. Thank you. That has now been fixed.

I have three cases to report as possible problem or a bug but have no time to extract that from the code. So here is simplest one.

More examples of not clear diagnostics. It is not related to Clearwin. If you forget to allocate an array you will get this confusing message

Run time error 420 Reference through NULL fortran POINTER

There are no pointers in the program. Could this be resolved with more relevant message?

Dan,

What do you mean by 'lazy allocation'?

Eddie

It was hard for me to write the words above (in the thread General about zeroising allocated arrays) suggesting to kill lazy allocation if it is not killed already.

Lazy allocation was the genial trick of this compiler which i still think saved my scientific life and made my codes over jump probably all other codes in the world by ages, even made by national labs with their infinite resources, and implement unbelievable features at the times when '640k was enough for everyone'.

This feature allowed to claim as used memory only those memory cells of the formally unimaginable 1 gigabytes size matrices ( in 1990 RAM sizes of PC were 1-2 MB) which were actually used. That means in the sparse matrices only allocated at the run time elements used tiny RAM of personal computers.

I remember i tried to compile my codes in other compilers and after half an hour compilation they were creating 350MB file while commonly we had only 1MB of RAM. Many supercomputers used just 250MB at that time. That was like a spit into your face! FTN77 though in seconds created tiny file and ran the code no one believed it is actually running.

And then finally with huge difficulties i got time on Cray supercomputers. Joke was that i was getting 1 hour per day while it was only 3 times faster than my FTN77 on a PC. Plus the diagnostics of their Fortran compilers was so terrible that i laughed in disbelief.

I remember i wrote to Salford a letter suggesting them to write compiler for supercomputers. I invited them to visit our place which was #1 in the world in computational resources having all 5 top places in the 'top 500 supercomputers' list there. I was sure their compiler would kill all others. But got no respond. Now China will only invite them 😃. I said byebye to supercomputers for a long time (just until few years ago). And then all other people my colleagues abandoned them in favor of PC or MAC.

The code

i = winio@ ('%^bt[OK]&', 
    'Exit') 

Gave error

*** Error 58: Unpaired right bracket(s)

which is correct given just fixed right-left wording but more relevant error is missing continuation symbol & at the end of first line

Yes an 'unpaired left bracket' report could occasionally be the result of a missing trailing ampersand. But would this rare mistake justify changing the report to 'unpaired left bracket or missing trailing ampersand'?

If there are 20 lines of continuation and 100 brackets in one line then sure yes

Dan,

If you program in that style, then you should expect His Satanic Majesty to occupy that particular tract of the underworld.

Especially when you could, instead, write a single line 1000 characters long!!!

Eddie

We see the trend that compilers become more and more capable and precise. So that we humans will be able continue to do more and more stupid things and not get caught. The most crazy programming style i saw was HTML file 40 KB in size all written in one single line. I am still far from that