Unexpected STATEMENT FUNCTION statement
VIJAY MANICKAM ACHARI
I have written subroutine in fortran90 to calculate distance among
three cartesient point using array.
The code is as below:
!#######################################################
subroutine find_distance(x,y,z, nATs, distance)
implicit none
!
! variables
integer, intent (in):: nATs
integer:: i
real, intent(out), dimension(nATs):: distance
real, intent(in):: x(:), y(:), z(:)
!
!
! declaration
do i= 1, nATs
ditance(i) = x(i) + y(i) + z(i)
end do
end
!###################################################
it states the comment as below:
[mbchgva2@samson ldp]$ gfortran -c coordinate-XYZ-read.f90
In file coordinate-XYZ-read.f90:70
ditance(i) = x(i) + y(i) + z(i)
1
Error: Unexpected STATEMENT FUNCTION statement at (1)
Can anyone help to trace why the Error message come as above?
Thanks in advance.
Vijay.M
Dave Allured
Because "ditance" is spelled wrong.
--Dave
Klaus Wacker
> HI,
>
> I have written subroutine in fortran90 to calculate distance among
> three cartesient point using array.
> The code is as below:
>
> !#######################################################
> subroutine find_distance(x,y,z, nATs, distance)
> implicit none
> !
> ! variables
> integer, intent (in):: nATs
> integer:: i
> real, intent(out), dimension(nATs):: distance
> real, intent(in):: x(:), y(:), z(:)
> !
> !
> ! declaration
> do i= 1, nATs
>
> ditance(i) = x(i) + y(i) + z(i)
This should probably be distance(i).
> end do
>
> end
>
> !###################################################
>
> it states the comment as below:
>
> [mbchgva2@samson ldp]$ gfortran -c coordinate-XYZ-read.f90
> In file coordinate-XYZ-read.f90:70
>
> ditance(i) = x(i) + y(i) + z(i)
> 1
> Error: Unexpected STATEMENT FUNCTION statement at (1)
>
>
> Can anyone help to trace why the Error message come as above?
Something like "name(expression)" to the left of an "=" can either be
an array element (or array section) or a statement function to be
defined. Since the mistyped ditance is not an array, it can only be a
statement function. But then it is out of place here, it has to come
before the first executable statement. Thats in short the logic of the
compiler which produced this error message.
Yes, the error mesage could be more helpful.
> Thanks in advance.
>
> Vijay.M
--
Klaus Wacker klaus....@udo.edu
Experimentelle Physik V http://www.physik.uni-dortmund.de/~wacker
Universitaet Dortmund Tel.: +49 231 755 3587
D-44221 Dortmund Fax: +49 231 755 4547
Richard Maine
> real, intent(out), dimension(nATs):: distance
...
> ditance(i) = x(i) + y(i) + z(i)
> Error: Unexpected STATEMENT FUNCTION statement at (1)
>
> Can anyone help to trace why the Error message come as above?
> Thanks in advance.
Others have mentioned what your error was. I'll try to at least briefly
explain why it is so cryptic. The syntax of a statement function
definition unfortunately overlaps very much with that of an assignment
statement for an array element. Pretty much the only way that the
compiler can tell the difference is that an array has to be declared as
such. So if the compiler doesn't see an array declaration, it assumes
the statement must be a statement function. (But then it gripes because
statement functions have to be up with the declarations instead of in
the middle of the executable code).
Humans also get confused by this simillarity of syntax, particularly as
statement functions as not used a lot. Many writers of Fortran have
never seen one and thus get confused when they do.
--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
John Harper
>VIJAY MANICKAM ACHARI wrote:
>>
>> HI,
>>
>> I have written subroutine in fortran90 to calculate distance among
>> three cartesient point using array.
>> The code is as below:
>>
>> !#######################################################
>> subroutine find_distance(x,y,z, nATs, distance)
>> implicit none
>> real, intent(out), dimension(nATs):: distance
...
>> end do
>> [mbchgva2@samson ldp]$ gfortran -c coordinate-XYZ-read.f90
>> In file coordinate-XYZ-read.f90:70
>>
>> ditance(i) = x(i) + y(i) + z(i)
>> 1
>> Error: Unexpected STATEMENT FUNCTION statement at (1)
Others have explained the reason for that error message, but my
question is: given that Vijay had used implicit none, why didn't
the compiler give the error message appropriate to distance being
declared but ditance being used? Or did it, but Vijay didn't tell us?
-- John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington 6140, New Zealand
e-mail john....@vuw.ac.nz phone (+64)(4)463 6780 fax (+64)(4)463 5045
Richard Maine
> Others have explained the reason for that error message, but my
> question is: given that Vijay had used implicit none, why didn't
> the compiler give the error message appropriate to distance being
> declared but ditance being used? Or did it, but Vijay didn't tell us?
I briefly wondered that as well. My guess is that the compiler first
decided this looked like a bad statement function statement. After all,
you have to parse the statement first in order to figure out what kinds
of things it has that need types.
feen...@nber.org
wrote:
> VIJAY MANICKAM ACHARI <vjram...@gmail.com> wrote:
>
> Yes, the error mesage could be more helpful.
>
Note to any compiler writers watching - there isn't any logical block
to adding:
"or undimensioned subscripted variable."
to the error message. While that might not cover every possibility, it
would save
an hour or so for every person learning Fortran for the first time,
since everyone makes this error at least once.
I remember many years ago getting the message "Illegal compiled
format" from the IBM G compiler at run time for a labeled format
statement. Actual problem was "Array write out of bounds". Since that
is the likely way to get an illegal compiled format, I thought it
churlish of IBM not to mention that possibility in "Messages and
Codes". All M&C said was "Probable user error. Correct error and
resubmit." Since then several people have brought me that error
message, often after several hours of fussing themselves. I appreciate
that my ability to diagnose that particular error instantly makes me
look clever, but I am not sure that it sells compilers. I should add
that I found a more informative error message in an IBM confidential
guide to error messages loaned to me by an ex-employee. It wasn't
clear why the helpful guide was confidential, while the published
version omitted the informative sentence.
One has to think of the "business purpose" for an error message, not
just the state of the parser.
Daniel Feenberg
paul.rich...@gmail.com
> Note to any compiler writers watching - there isn't any logical block
> to adding:
>
> "or undimensioned subscripted variable."
>
> to the error message. While that might not cover every possibility, it
> would save
> an hour or so for every person learning Fortran for the first time,
> since everyone makes this error at least once.
Would "or an assignment to an undeclared array" do it for you? Either
way, it can be "made so" trivially:-)
Cheers
Paul
Arjen Markus
I'd say that is even clearer - as statement functions are
an obscure functionality, it is much more likely that an
array was meant, so using that term should encourage people
to look a bit closer.
Regards,
Arjen
glen herrmannsfeldt
(snip)
> I remember many years ago getting the message "Illegal compiled
> format" from the IBM G compiler at run time for a labeled format
> statement. Actual problem was "Array write out of bounds". Since that
> is the likely way to get an illegal compiled format, I thought it
> churlish of IBM not to mention that possibility in "Messages and
> Codes". All M&C said was "Probable user error. Correct error and
> resubmit."
The possibility of writing over executable code by going
outside an array was always suggested as a possibility.
Even so, I don't know of many cases where it actually happened.
(Though I am not sure if compiled format counts as code or data.)
Still, one should always beware of unusual problems going
outside array bounds. Mentioning it for every message in the
manual seems excessive.
-- glen
robin
news:1ioi405.1q3n1nrqnq1seN%nos...@see.signature...
> John Harper <har...@mcs.vuw.ac.nz> wrote:
>
> > Others have explained the reason for that error message, but my
> > question is: given that Vijay had used implicit none, why didn't
> > the compiler give the error message appropriate to distance being
> > declared but ditance being used? Or did it, but Vijay didn't tell us?
>
> I briefly wondered that as well. My guess is that the compiler first
> decided this looked like a bad statement function statement.
It's a perfectly good function statement.
(were it placed before executable statements, it would compile
without error.)
In that case, of course, without anything else done,
IMPLICIT NONE would catch the name.
> After all,
> you have to parse the statement first in order to figure out what kinds
> of things it has that need types.
At that point in the program, the compiler should not be looking for
function statements.
robin
> VIJAY MANICKAM ACHARI <vjra...@gmail.com> wrote:
> ...
> > real, intent(out), dimension(nATs):: distance
> ...
> > ditance(i) = x(i) + y(i) + z(i)
> ...
> > Error: Unexpected STATEMENT FUNCTION statement at (1)
> >
> > Can anyone help to trace why the Error message come as above?
> > Thanks in advance.
>
> Others have mentioned what your error was. I'll try to at least briefly
> explain why it is so cryptic. The syntax of a statement function
> definition unfortunately overlaps very much with that of an assignment
> statement for an array element. Pretty much the only way that the
> compiler can tell the difference is that an array has to be declared as
> such. So if the compiler doesn't see an array declaration, it assumes
> the statement must be a statement function. (But then it gripes because
> statement functions have to be up with the declarations instead of in
> the middle of the executable code).
Some compilers, such as the free Silverfrost compiler,
diagnose the error correctly as an undeclared array.
Once the first executable statement in a procedure has been encountered,
there's no reason for the compiler to look for function statements.