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, 6, 7, 8  Next
 
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: 1215

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: 2124
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: 1215

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: 2124
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: 1215

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: 2124
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: 1232
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
DanRRight



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

PostPosted: Sat Sep 14, 2019 12:21 am    Post subject: Reply with quote

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' ?

Code:
    integer function Select_PL_f_E_withAngleSlider)


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


Last edited by DanRRight on Sat Sep 14, 2019 9:40 am; edited 1 time in total
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


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

PostPosted: Sat Sep 14, 2019 8:16 am    Post subject: Reply with quote

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



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

PostPosted: Sat Sep 14, 2019 10:15 am    Post subject: Reply with quote

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

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



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

PostPosted: Sat Sep 14, 2019 10:22 pm    Post subject: Reply with quote

I see your confusion Dan, submit a program with NO main program and the compiler tells you there is more than one !

I do admire the A.I. of the compiler though, starts off with 3 errors and then reduces it to 2 !

or is it that it finds 3 errors in the first main program and then anther 2 in 'the other' one ?

As good excuse as any to break out the martinis with olives the size of basketballs ! Smile
_________________
''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
John-Silver



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

PostPosted: Sat Sep 14, 2019 10:25 pm    Post subject: Reply with quote

As for:-
Quote:
error 58 - Unpaired right bracket(s)

I object m'lord to it's use !
Surely it would be better (aand more correctly) written as:-
Quote:
'Missing left bracket (s)'

I think that proves the point Dan has often made.
_________________
''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
JohnCampbell



Joined: 16 Feb 2006
Posts: 2144
Location: Sydney

PostPosted: Sun Sep 15, 2019 2:04 pm    Post subject: Reply with quote

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

Not always the case !!
Back to top
View user's profile Send private message
mecej4



Joined: 31 Oct 2006
Posts: 1215

PostPosted: Sun Sep 15, 2019 4:21 pm    Post subject: Reply with quote

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

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:

a) Function names cannot contain ')'

b) Malformed function argument list

c) Orphaned right parenthesis

d) ')' 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:

i) confusing '(' with '[', '<' or '{'

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



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

PostPosted: Mon Sep 16, 2019 3:23 am    Post subject: Reply with quote

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 Smile 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.
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, 6, 7, 8  Next
Page 5 of 8

 
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