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 

Not Clear diagnostics
Goto page Previous  1, 2, 3, 4, 5
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> ClearWin+
View previous topic :: View next topic  
Author Message
mecej4



Joined: 31 Oct 2006
Posts: 1155

PostPosted: Wed Jul 24, 2019 1:26 am    Post subject: Reply with quote

Here is what the compiler said:
Code:
[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.
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Jul 24, 2019 1:38 am    Post subject: Reply with quote

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 ?
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1155

PostPosted: Wed Jul 24, 2019 3:18 am    Post subject: Re: Reply with quote

DanRRight wrote:
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.

Quote:
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.

Quote:
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.


Last edited by mecej4 on Wed Jul 24, 2019 8:03 am; edited 1 time in total
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Jul 24, 2019 5:02 am    Post subject: Reply with quote

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 Smile

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:

Code:
*** 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"
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1155

PostPosted: Wed Jul 24, 2019 12:20 pm    Post subject: Re: Reply with quote

DanRRight wrote:

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

Code:
*** 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.

Quote:

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?
Back to top
View user's profile Send private message
DanRRight



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

PostPosted: Wed Jul 24, 2019 8:12 pm    Post subject: Reply with quote

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 Smile. 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 Smile

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?
Back to top
View user's profile Send private message
John-Silver



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

PostPosted: Fri Jul 26, 2019 8:14 pm    Post subject: Reply with quote

I think the 'problem is more fundamental, and 2-fold.

mcej4, in reply to Dan's ....

Quote:


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


you replied ...

Quote:
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?


which while correct, does little for the understanding of the average Joe.

You have to take it down to the basic level, a user is a complex beast (aren't all humans) but require a very simple indication of the problem, followed where possible by a simple 'that's because' and in an džideal world a list of possible causes/solutions.

as Eddie (no not that one) said ...

There are 3 steps to bug-busters heaven if you like.

Step 1: ERROR
Problem writing expression <> to memory during processing of the READ statement.

Step 2: POSSIBLE CAUSES
A variable in the expression be incorrectly declared
A function may have been inadvertently included in the list of variables to be read.

Step 3:POTENTIAL RESOLUTIONS:-
Check that declarations of variables beinf read are valid
Check that a function has not been declared in error in Read variables list
Check ....... etc .... etc ....
(List of possibl causes to be reviewed and augmented as and when identified)

So, let the Silverfrost development of the all dancing all singing ShowTheBugBuddy project begin !
_________________
''Computers (HAL and MARVIN excepted) are incredibly rigid. They question nothing. Especially input data.Human beings are incredibly trusting of computers and don't check input data. Together cocking up even the simplest calculation ... Smile "
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 -> ClearWin+ All times are GMT + 1 Hour
Goto page Previous  1, 2, 3, 4, 5
Page 5 of 5

 
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