Not Clear diagnostics

Quoted from PaulLaidler So a 'crash' is this context is not caused by a fault in the library but is a mechanism for helping you to find bugs in your code.

In a few cases the call to clearwin_error has been modified to give you the choice of continuing. Other cases could be identified as time permits but, as a general rule, continuation is either not possible or not advisable.

I like this addition you have made working on crashing case from another thread introducing the option not to crash GUI, specifically %pl. And even more specifically like the pre-screening of input data which informs the user what could be potentially wrong (for example 'Data corrupted in array variable #3, element #3233' etc.). This choice of continuing seems is great for both worlds: it allows to ignore execution of %xx control and avoid the crash with that (and potentially find the reason), OR to continue and have a crash of entire code (which usually has nothing wrong) for those who can read access violation binary gibberish and detect the error in Clearwin by that. Probably there were only couple people in 30 years who in 1% cases have succeeded to decipher such diagnostics. All these few cases were not with Clearwin for sure 😃

If anyone disagree and still likes to see for more 30 years such useless crash screens like below let's do the test: can you tell me what's the error i made (or is this the bug?) which crashes my program for last 10 years in property sheet %ps ? Good 10 years old whiskey is yours

Dan

You exaggerate again! 64 bit FTN95 was first released in 2016.

What does this trace back look like for a 32 bit executable built using /DEBUG or better /UNDEF? Have you tried running the 32 bit version via SDBG?

I do not exaggerate a tiny bit, this first started long ago and the code crash in both 32 and 64 cases. Of course i ran it with all possible switches. Does not crash only if i launch this code via debugger (even if compile with /nocheck). This and fixed two days ago crash of graphics were (and this one still current) are my major problems with Clearwin.

I had bad luck with READ/WRITE in Fortran all my life. This is 100x worse than Clearwin+ which eventually is fun. Here is one more example of unacceptably bad elitist diagnostics typical for Fortran, not just FTN95. I've spent one more swearing hour to find what's wrong plus then some time scaling complex read statement which abruptly started to hiccup. Here is complete demo.

Read(1,'(i3, E10.3)') i, A(i)
end

And here is diagnostics which would cause anyone to hate Fortran. Pure devilry, it worked today OK. I had to stop today.

0001) Read(1,'(i3, E10.3)') i, A(i)
*** Non-writable expression in READ statement
*** Compilation abandoned

Bet that the person who have done that hated and did not use Fortran, was lazy or was a total snob. Could it be that this was the same person who wrote FTN90 ? 😃))

And also lazy users...is a PITA. Not so many really active people FTN95 has. I propose to introduce system of ratings. The higher score people get the more priority they obtain in fixing found bugs. Such ratings have many other forums. May be this will stimulate people to report problems and suggest improvements.

C'mon guys, please try to guess what the heck is this error. I tried to spend 15 minutes on it and already 1 day passed. At least please confirm that you get the same cryptic error and my compiler or computer is not corrupted. 20 lines before this place in my code similar READ works 😭

You did not provide a declaration for A(i) and you do not permit yourself to specify IMPLICIT NONE, so the compiler did the best it could.

The following test code contains two copies of a READ statement that fits your description. Only the second copy causes the '...non writable' message, and the program listing contains a hint for the resolution of the error.

program tst
real A(4)
open(10,file='xyz.dat',status='old')
read(10,'(i3,E10.3)')(j,A(j),i=1,4)
call sub(A,4)
end

subroutine sub(A,n)
! real A(n)
do i=1,4
   if(A(i) .le. 0.0)then
      read(10,'(i3,E10.3)')j,A(j)
   end if
end do
return
end

Thanks mecej4. If you'd take a bear or vodka per compiler accidents, your be in danger 😃 Tell me where to send you better quality whiskey instead.

First, do you get the same diagnostics ? It is important for me to continue or not. Fun is that i knew about non-declared array and knew that there would be no error if i declare it, and i checked all variables in READ list and they are all defined.

Then are you happy with the diagnostics wording? May be i'm wrong, i'm not an English speaking and to me it looks like a spewed nonsense besides the bad diagnostics. If you have other compilers what they say about this error?

Here is what the compiler said:

[FTN95/Win32 Ver. 8.51.0 Copyright (c) Silverfrost Ltd 1993-2019]
    NO ERRORS  [<TST> FTN95 v8.51.0]
0012)       read(10,'(i3,E10.3)')j,A(j)
*** Non-writable expression in READ statement
*** Compilation abandoned

The execution of a READ statement causes values to be read into variables, i.e, written into the corresponding memory locations. Those locations have to be writable. In the I/O list we have j and A(j). Since j is not an INTENT(IN) argument, it is writable. We are left with A(j). The variable A is a dummy argument to the subroutine, and it has not been dimensioned. What does A(j) mean in such circumstances? It must be a function invocation: A is the name of a function. However, a function reference cannot be an input item in a READ statement; i.e., a function reference is not a writable expression.

Other languages such as Pascal or C remove this ambiguity in the notation. A[j] is element j of array A, and A(j) is function A with argument j.

One has to remember that the compiler has to operate with the (mis)information that the programmer has provided. That limited information may not suffice to pinpoint the error, or there may be a number of different ways in which the Fortran statement is erroneous, and we should not expect the compiler to guess what the programmer had in mind when (s)he wrote the code.

OK. If this is what was meant by this diagnostics wording then it is very bad. It is not more usable than binary address in a crash report. Only few may get a clue from it. You have few other Fortran compilers, curious, what they say in this specific case ?

Quoted from DanRRight OK. If this is what was meant by this diagnostics wording then it is very bad.

Unsubstantiated opinions are ten a penny. I can think of at least three different diagnostics in the circumstances, but I doubt that they will elicit approval from you.

Instead, do the following. You have the code that I posted above and you know what the error in that code is. Propose an appropriate diagnostic message and offer a coherent argument to support that proposal. If Paul is persuaded by your arguments, who knows, the next revision of FTN95 may well be adorned with your wording of the diagnostic message.

It is not more usable than binary address in a crash report. Only few may get a clue from it.

There are circumstances in which you can have nothing else. For example, when there is an optimization bug and the crash report with hex addresses and register and memory dumps is all we have, and that has to suffice.

You have few other Fortran compilers, curious, what they say in this specific case ?

So do you. Find out for yourself and make those compilers also the beneficiaries of your scorn.

I exterminated other compilers from my harddrives and CD collections a decade(s) ago. Do not afraid to show what other compiler diagnostics says to the user, you may do that anonymously Compiler 1, Compiler 2, Compiler 3 etc... if this compiler wording is more on elitist side, other expected to look more dumb or funny. Or do not find this as an error 😃

It's not me who should propose wording for English speaking people, specifically as elitists as UK. Even my own ideas sound much better when they are written and spoken by native English language bearers. But there i am a specialist and know stuff on as deep level as not only binary but the single electron position level

And because of that the clarity, simplicity and depth of diagnostics is paramount to me.

But an obvious suggestion for improvements of this message i can easily give based on the obvious:

*** Either not declared array A(j) or not defined function A(j) in READ statement

And this would be tremendous improvement because compiler points on wrong element in the READ list which in my case may contain 20 different variables, not just two like in this small snippet. You can reword it into proper English and add other options. Definitely the current 'non-writable expression' is totally laughable. We are reading something but message talks about writing

And major fun provides Wikipedia 'Non-writable expressions are expressions of the programmer learning Clearwin+ which are forbidden to write for public consumption'

Quoted from DanRRight

... But an obvious suggestion for improvements of this message i can easily give based on the obvious:

*** Either not declared array A(j) or not defined function A(j) in READ statement

The first part can be made tolerable (note that if A is an array, A(j) is an array element), and the second part cannot be obvious because it is simply wrong. Under implicit typing rules, functions have implicit interfaces and are assumed to be external. Their definitions may be in a separate file, in a different language or in a pre-compiled library. Secondly, there is no rule that prevents a function reference from appearing in a subscript expression in a member of an input list.

Definitely the current 'non-writable expression' is totally laughable. We are reading something but message talks about writing.

All formatted I/O operations involve (i) reading from a device, (ii) (optional) modification of the data read and (iii) writing to a device. 'Device' includes memory, data channel or hardware such as disk drives, printers, etc. The READ statement that you showed involves (i) reading a formatted record from a disk file on Unit-10, (ii) modification according to the format specification, and (iii) writing to the corresponding item in the input list. If the input list item is a function name instead of a variable name, that item is not writable, so action (iii) is not allowed.

Are you still laughing?

Of course from now the 'non-writable expression' (NWE)will be a one of the laughable slogans for Fortran diagnostics. Even the best diagnostics compiler like FTN95 fell short of being reasonable sometimes.

As to your comments to my rewritten diagnostics message - i just compiled there your own considerations 😃. And what potentially spurious A(j) as a function is doing in the READ (what i meant)? So your finesse on how Fortran handles functions is irrelevant, I don't know what are you drinking, i offer you good old whiskey instead 😃

Further your details just put more water on a wheel of my suggestion to company: please make diagnostics more clear, specific and detailed, not more elitist diagnostics with NWE. For Fortran to be compiler of broader base masses it has to write its error messages for these masses.

For example FTN95 can leave zero level of error reporting as it is currently but add next level with the switch like /ErrorDetails which will tell user as much as possible detailed info where specifically on mentioned i) or ii) or iii) or may be iiii) or even iiiii) compiler was unhappy with its non-writable expressions.

You probably will be OK with solving one more NWE puzzle, but majority of others i'm sure will better save time and get some clue from additional info of compiler. Besides many times bitten Clearwin+ which with time becomes better and better, the FTN77/90/95 READ error diagnostics stays the same poor, cryptic and elitist. It always was the weakest point of this compiler where users learn many English idioms and swear using very non-writable expressions. Are you still laughing?

I understand users may make terrible stuff not decipherable to any compiler in the world but how about this one symbol of left parenthesis loss error ? Where is 'S' ?

    integer function Select_PL_f_E_withAngleSlider)

889. integer function Select_PL_f_E_withAngleSlider) *** Error 820: 'S' found after FUNCTION where a comma was expected
890. end function *** Error 764: Nesting error - the MODULE construct on line 46 has not been terminated

The context is exceptional. Normally you would get...

error 58 - Unpaired right bracket(s)

In any case the line number is presumably correct and the error is easy to spot.

Yes, normally you would get that, and you'd get that if compile just the function separately not in the module, but here in the module diagnostics is a pure hell. I show here the complete text:

 Module All_subs
 use clrwin
integer ih
contains 

  integer function Select_Slider)
  i=select_graphics_object@ (ih)
  Select_Slider  = 2
  end function 

end module

and the error message from the hell

    PROCESSING MODULE  [<ALL_SUBS> FTN95/Win32 v8.51.0]
0006)   integer function Select_Slider)
*** 'S' found after FUNCTION where a comma was expected
0009)   end function 
*** Nesting error - the MODULE construct on line 1 has not been terminated
0006)   integer function Select_Slider)
*** Unpaired right bracket(s)
        3 ERRORS  [<main program> FTN95 v8.51.0]
    NO ERRORS  [<ALL_SUBS> FTN95 v8.51.0]
0011) end module
*** More than one main program encountered
*** Nesting error - the PROGRAM construct on line 11 has not been terminated
    2 ERRORS  [<main program> FTN95 v8.51.0]
*** Compilation failed

'Missing left bracket (s)' implies that the right bracket should be there.

Not always the case !!

I think that some of these comments are rather harsh, and even seem to expect the compiler to be clairvoyant. Take, for example, Dan's line of code

integer function Select_Slider)

Let's assume that this is not a continuation line (i.e., the previous non-comment non-empty line did not end with '&' in free-form source), and that this line is not within the unfinished body of a program unit. Suppose that the compiler has digested the tokens 'integer' and 'function'. In Fortran, what follows must be one of :

1. A function name, OR

2. A function name, followed by an argument list within parentheses, OR

3. The items under 2., followed by a result clause.

(I exclude the fixed form absurdity that this could be an attempt to declare an integer variable with the name 'functionSelect_Slider', with ')' added as a typo.)

Note that with pattern 1, we have a function with no arguments. There are very few such functions, but they do exist.

What the compiler sees in Dan's line does not fit any of these patterns. What's an appropriate message to issue? Some possibilities:

1. Function names cannot contain ')'

2. Malformed function argument list

3. Orphaned right parenthesis

4. ')' unexpected

Please note that if the compiler had used John Silver's choice phrase 'Missing left bracket (s)', that would have been objectionable on two counts:

1. confusing '(' with '[', '<' or '{'

2. incorrectly claiming that a function declaration must contain a left bracket (or left parenthesis).

I would say, please note the line number, take the words of the message without being too critical, fix your code and move on.

There have existed a few programming languages whose design gave thought to issuing clear compile time error messages (e.g., Wirth's Pascal). Fortran is not one of them. Fortran is harder to parse than many other languages -- one reason: there are no reserved words --, and I am amazed by what Fortran compilers are able to accomplish nevertheless.

Brilliant, mecej4. You have forgotten to comment the compiler's verdict

'*** 'S' found after FUNCTION where a comma was expected'

Though i fixed this particular error I am still scratching my head about 'S' compiler mentioned 😃 and why without being in module the error diagnostics is different.

My major point is that the diagnostics like that have to be a past. They came from the times when memory of computers was 64 kbytes and 640k was the dream which supposed to be enough for everyone. Eventually diagnostics have to use artificial intelligence and work with the users, babysit the user, explaining things. Right now all compilers in the world just take the stick and hit the user on his head with their un-writeable expressions you have to decipher be you a novice or 40 years of experience. Novices will not stick with Fortran with such diagnostics messages.

Dan, you and I have a handicap. When we see a compiler error message that we cannot make sense of, we look at the line in the source code that is causing the error; we usually know what we wanted to say in that line of code, but the compiler does not. The compiler and we humans differ greatly in the amount of context that we are able to include in our reasoning.

Novices will not stick with Fortran with such diagnostics messages

Novices will have to be patient and get help and advice as needed, as with learning to ride a bicycle. You can make things 'as easy as falling off a horse', but the novice will still need to procure a horse and seek help to get on the horse before reaching the goal of falling off, and have a backup plan for what to do after reaching the goal.

Dan, do me a favor. Look at the commands and the corresponding error messages from the Unix shell, in the collection at https://www.gnu.org/fun/jokes/unix.errors.html . After you finish laughing, for at least a few of the cases, (i) try to explain *why * the program (the sh/bash shell) gave the responses that it did and (ii) give your own novice-friendly answer.