FORTRAN 90 'PARAMETER' Scope
pwillis
I am wondering about the scope of the parameters when included in my
main source.
I have a FORTRAN 90 program with an included parameter file.
ie:
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! MY PARAMETER FILE
! MY_PARAMS.f90
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
integer, parameter :: m=267,n=115,msoc=0,nh=3,nb=458,l=22,lo=36
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! MY MAIN FILE
! MY_MAIN.f90
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
program main
include 'MY_PARAMS.f90'
common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
.
.
.
!!!!!!!!!!!!!!ETC
Compilation complains about the 'common' block declaration if I use
the
'include' statement, however if I just put the parameter declaration
in
'my_main.f90' directly everything compiles fine.
Is the scope of parameters in an include file limited to the include
file?
Can I expand the scope or use an external declaration of some type?
Thanks for any help.
P
steve
>
> Compilation complains about the 'common' block declaration if I use
> the 'include' statement,
If you want help, it would be prudent to include the exact text
issued by the compiler instead of paraphrasing. Additionally,
a complete short program would also be helpful because the
two code fragments are insufficient for anyone to guess the
problem.
integer, parameter :: m=267,n=115,msoc=0,nh=3,nb=458,l=22,lo=36
program main
include 'a.f90'
common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
end
troutmask:kargl[204] cat a.f90
integer, parameter :: m=267,n=115,msoc=0,nh=3,nb=458,l=22,lo=36
troutmask:kargl[205] cat b.f90
program main
include 'a.f90'
common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
end
troutmask:kargl[206] gfc -o z b.f90
b.f90:3.56:
common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
1
Error: Variable 'lv' cannot appear in the expression at (1)
b.f90:3.55:
common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
1
Error: The module or main program array 'dv' at (1) must have constant
shape
dpb
...
> I am wondering about the scope of the parameters when included in my
> main source.
They have the scope of the program unit within which they are defined
just as any variable.
...
> ! MY_PARAMS.f90
> integer, parameter :: m=267,n=115,msoc=0,nh=3,nb=458,l=22,lo=36
...
> program main
> include 'MY_PARAMS.f90'
> common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
>
...
> Compilation complains about the 'common' block declaration if I use
> the 'include' statement, however if I just put the parameter declaration
> in 'my_main.f90' directly everything compiles fine.
...
The most likely case then is that the include file isn't in the path
being searched and therefore isn't being INCLUDEd in the file but that's
a surmise since "complains about" isn't sufficient to know what,
specifically the complaint is.
Or, it's possible there's a problem w/ the contents of the file;
possibilities include things like a TAB character or other
non-displaying character or perhaps (I'm not positive on this one but
it's at least plausible I think) there's not a line terminator on the
one line in the file so it isn't seen as a complete line. Anyway, I'd
suggest double-checking that the content is what you think it is w/o any
such problems.
The INCLUDE statement simply inserts the text of the file named into the
source file at that point; no more, no less. Hence, it isn't anything
esoteric about scope or such; something is wrong w/ either the file
content itself or it isn't being found or somesuch relatively trivial
matter.
--
Richard Maine
> On Aug 25, 4:01 pm, pwillis <silliw.re...@gmail.com> wrote:
>
> >
> > Compilation complains about the 'common' block declaration if I use
> > the 'include' statement,
>
> If you want help, it would be prudent to include the exact text
> issued by the compiler instead of paraphrasing. Additionally,
> a complete short program would also be helpful because the
> two code fragments are insufficient for anyone to guess the
> problem.
I'll second Steve's comments and add just one direct answer.
No, nothing has the scope of an include file. Include files have nothing
to do with scope. Nor is the scope of a parameter different from the
scope of anything else.
But basically, you'll need to give us, as Steve suggests, the actual
data. Ideally that would be a complete small sample with which to
reproduce the problem, but at the very least, the exact error message.
It isn't likely to be nearly as constructive for you to just offer up
your theories as to what might be wrong. We could go through an awful
lot of incorrect theories that way before hitting the right one (and we
probably would not have the data to know when we had hit it).
Do notice, as Steve's reply illustrated, that your common block appears
to reference something called lv, which is not shown in your include
file. If that's the problem, it would have nothing to do with include
files, scope, or anything else so esoteric. That would sound a lot more
like just failing to correctly copy the declarations in question into
the include file. I suspect Steve was probably hinting at that by
showing the error messages he got, but you might not have picked up on
the hint. (Or maybe I'm imagining it as a hint.)
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
robin
"pwillis" <silliw...@gmail.com> wrote in message
news:a1b63218-ac5d-436e...@s24g2000pri.googlegroups.com...
| Hello,
|
| I am wondering about the scope of the parameters when included in my
| main source.
| I have a FORTRAN 90 program with an included parameter file.
|
| ie:
| !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
| ! MY PARAMETER FILE
| ! MY_PARAMS.f90
| !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
|
| integer, parameter :: m=267,n=115,msoc=0,nh=3,nb=458,l=22,lo=36
|
|
| !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
| ! MY MAIN FILE
| ! MY_MAIN.f90
| !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
| program main
| include 'MY_PARAMS.f90'
| common /y1/u(2,l,m,n),uab(2,l,m,n),tb(2,m,n),dv(lv),dap(l)
| Thanks for any help.
Put IMPLICIT NONE in your program.
pwillis
This is now resolved.
The problem was in the include file which was problematically named
with a .f90 file extension.
File name extension for an F90 include file is better as '.inc' or
'.fi' due to the compiler treating
them differently.
In this case the .f90 file will not compile without errors if there is
no code termination
at the end of the file. Hence there was an 'end' statement erroneously
placed at the bottom
of the include file.
Once included in the 'main' program code, the compiler treats the
'end' in the include file
as the end of the main routine.
The scope of the included parameters is this constrained to the
prematurely terminated
'main' routine and cannot be used by the following common block that
is now outside the main
program body.
The solution was to rename the include file with extension '.fi' and
remove
the erroneous 'end' statement from the end of the include file.
Thanks to all those who provided comments. Many of those things I had
already looked into. It was good of everyone to respond with
so much useful information.
I'm off to check the rest of the include files now.
Best Regards,
Peter
On Aug 25, 4:01 pm, pwillis <silliw.re...@gmail.com> wrote:
dpb
...
> The problem was in the include file which was problematically named
> with a .f90 file extension.
> File name extension for an F90 include file is better as '.inc' or
> '.fi' due to the compiler treating
> them differently.
How so? I can't see any reason whatever that the file name for an
INCLUDEd file couldn't be _any_ OS-consistent valid file name.
The overall source file in which the INCLUDE statement resides will
likely indicate free/fixed source format for most current compilers but
that's totally separate from an include file.
>
> In this case the .f90 file will not compile without errors if there is
> no code termination
> at the end of the file. Hence there was an 'end' statement erroneously
> placed at the bottom
> of the include file.
>
> Once included in the 'main' program code, the compiler treats the
> 'end' in the include file as the end of the main routine.
Of course...
As noted previously, _ALL_ the INCLUDE statement does is to insert the
contents of that file into the file stream at that point -- it's no
different than as if the same lines were inserted physically. One would
not manually include an END statement prematurely; thus one shouldn't
include one in a file to be used as an INCLUDE file unless it's the very
last thing in the source file program unit.
...
> The solution was to rename the include file with extension '.fi' and
I'm convinced this was totally immaterial and irrelevant and had nothing
to do w/ the problem.
> remove
> the erroneous 'end' statement from the end of the include file.
...
Yes, that would fix the problem outlined above.
A secondary lesson to be learned from this is that the posting of the
question would have provided the direct answer it the displayed contents
of the include file had been complete and the actual error message
generated displayed. As noted by others, doing so when posting future
questions will go a long way towards getting accurate and quicker
resolution.
--
dpb
...
> In this case the .f90 file will not compile without errors if there
> is no code termination at the end of the file. Hence there was an
> 'end' statement erroneously placed at the bottom of the include file.
...
Just dawned on me...if this was done in response to my comment about an
unterminated line in the include file, we had "a failure to
communicate". I did _NOT_ mean a Fortran END statement; I meant an
unterminated text line in the include file that wasn't seen as a
complete and terminated line of text by the compiler.
--
glen herrmannsfeldt
> pwillis wrote:
>> The problem was in the include file which was problematically named
>> with a .f90 file extension.
>> File name extension for an F90 include file is better as '.inc' or
>> '.fi' due to the compiler treating
>> them differently.
> How so? I can't see any reason whatever that the file name for an
> INCLUDEd file couldn't be _any_ OS-consistent valid file name.
> The overall source file in which the INCLUDE statement resides will
> likely indicate free/fixed source format for most current compilers but
> that's totally separate from an include file.
I believe so, but it can still be confusing to humans, and so
it is probably better to have another name. It seems that .inc
is popular, and will remind people where to expect the file to
be used. The .f90 extension will cause people to try to compile
that file.
It is common in C not to include executable statements in #include
files, though the compiler doesn't care. Similar conventions might
be useful in Fortran, too.
-- glen
dpb
I wasn't _recommending_ other as a wise or good practice; simply trying
to make the point of what INCLUDE does and that the name wouldn't be
looked at by the compiler to determine characteristics of the file
(altho I guess it is possible that one could go so far as to implement
parsing to the point of interpreting fixed- or free-form source format
on that basis I'm unaware any has done that???).
--
Ron Shepard
dpb <no...@non.net> wrote:
> > It is common in C not to include executable statements in #include
> > files, though the compiler doesn't care. Similar conventions might
> > be useful in Fortran, too.
No, because include files are used very differently in C than in
fortran. In C, include files usually have declarations and macros
that are shared by many programs to keep things consistent. Fortran
has modules for that purpose. In fortran, include files are used
for source code that is common to several different subroutines with
different declarations, for example, the repetitive body of a
subprogram compiled with different combinations of KIND parameters.
I've written code where the multiple instances of a set of
subroutines consisted ONLY of defining the KIND parameters (just one
or two lines of code), and the include text contained the
parameterized declarations of the variables and the subroutine body.
That about as opposite to the C approach as you could possibly get.
> I wasn't _recommending_ other as a wise or good practice; simply trying
> to make the point of what INCLUDE does and that the name wouldn't be
> looked at by the compiler to determine characteristics of the file
> (altho I guess it is possible that one could go so far as to implement
> parsing to the point of interpreting fixed- or free-form source format
> on that basis I'm unaware any has done that???).
In principle, this is a problem but in practice it isn't. If you
try to use include files to import parameters and such (as is common
in C), then you are faced with this problem. However, it is
possible to write include files that can be imported into either
fixed or free-form source code (avoid continuation lines, keep the
code between columns 7 and 72, etc.). If instead you use modules
for this purpose, then it is perfectly fine to use a module written
in free-form source in a fixed-form subprogram (or visa versa).
This is one of many advantages of modules over include files for
this purpose.
It is almost impossible to write C programs without using include
files (header files). In fortran, you could write millions of lines
of code and never need an include file. So however you think
include files should be handled in fortran, it just isn't a big
deal, and consequently it is unlikely to be changed in the future,
particularly in a way that is incompatible with past conventions.
$.02 -Ron Shepard
Richard Maine
> pwillis wrote:
> ...
> > File name extension for an F90 include file is better as '.inc' or
> > '.fi' due to the compiler treating
> > them differently.
>
> How so? I can't see any reason whatever that the file name for an
> INCLUDEd file couldn't be _any_ OS-consistent valid file name.
I can, but for indirect reasons. It occurs to me that some of those
indirect reasons might have, at one point, been relevant to the OP and
just described a bit vaguely or perhaps misunderstood.
Yes, a include file ought to work largely regardless of file name. But
it occurs to me that having an include file with a .f90 file name could
cause problems elsewhere than in the include. For example, a Makefile or
other build system might well assume that all *.f90 files were to be
compiled as "top-level" files. If one of them were an include file, the
include part would still work fine, but then things would fail when the
system also tried to compile it as a separate "top-level" file. I have
seen things like that happen. I think I've even seen problems like that
come up in this forum, perhaps in regard to making GUI "projects".
dpb
> In article <i567hi$2as$1...@news.eternal-september.org>,
> dpb <no...@non.net> wrote:
>
>>> It is common in C not to include executable statements in #include
>>> files, though the compiler doesn't care. Similar conventions might
>>> be useful in Fortran, too.
>
> No, because include files are used very differently in C than in
Nota bene dpb (I) wasn't the one who wrote the sentence to which you're
replying here...
>> I wasn't _recommending_ other as a wise or good practice; simply trying
>> to make the point of what INCLUDE does and that the name wouldn't be
>> looked at by the compiler to determine characteristics of the file
>> (altho I guess it is possible that one could go so far as to implement
>> parsing to the point of interpreting fixed- or free-form source format
>> on that basis I'm unaware any has done that???).
>
> In principle, this is a problem but in practice it isn't. If you
> try to use include files to import parameters and such (as is common
> in C), then you are faced with this problem. However, it is
> possible to write include files that can be imported into either
> fixed or free-form source code ...
Indeed, just as it is possible to write source in a form that is
decipherable as either (since all an included file is is a stream of
text, that's pretty much a given).
_ALL_ I was trying to do in both of the previous posts was to point out
to the OP of the thread where it seemed to me he was making far too much
out of INCLUDE as being more than what it is; namely simple inline text
substitution.
--
dpb
...
> Yes, a include file ought to work largely regardless of file name. But
> it occurs to me that having an include file with a .f90 file name could
> cause problems elsewhere than in the include. For example, a Makefile or
> other build system might well assume that all *.f90 files were to be
> compiled as "top-level" files. If one of them were an include file, the
> include part would still work fine, but then things would fail when the
> system also tried to compile it as a separate "top-level" file. I have
> seen things like that happen. I think I've even seen problems like that
> come up in this forum, perhaps in regard to making GUI "projects".
Indeed, that would be an issue -- as noted in reply to Ron S all I was
trying to do was to get the message across to the OP that all an include
file is is a text substitution. There seemed to be much more made of
INCLUDE than there is to be made of it in his postings.
I'd certainly agree it is wise to use something else than the
traditional source file extensions for those reasons and undoubtedly
should have been more careful in the pedagogical vis a vis the practical
aspects was trying to elucidate than was...
--
Richard Maine
> as noted in reply to Ron S all I was
> trying to do was to get the message across to the OP that all an include
> file is is a text substitution. There seemed to be much more made of
> INCLUDE than there is to be made of it in his postings.
Understand and agree. I have seen simillar mistakes made elsewhere, so
the point can be worth emphasizing. In particular, some people are so
used to END as being the last thing in a source file that they associate
it with the end of the source file instead of with the end of a scoping
unit. Thus, they put an inappropriate END statement at the end of their
include files; I've seen that one before, although I didn't initially
have the data to recognize it as being the case here.
I suppose it might be worth pointing out one niggly bit about include
files, though. They aren't quite 100% transparent text inclusion because
of this bit. It could well be a niggly bit that many regulars don't even
know about, as you could go a long time without getting bitten by it.
Although, as noted in this thread, an include file has nothing to do
with scoping unit boundaries, it does have to do with statement
boundaries. You cannot continue a statement across a boundary either
into or out of an include file.
glen herrmannsfeldt
(snip on include file naming)
> I wasn't _recommending_ other as a wise or good practice; simply trying
> to make the point of what INCLUDE does and that the name wouldn't be
> looked at by the compiler to determine characteristics of the file
> (altho I guess it is possible that one could go so far as to implement
> parsing to the point of interpreting fixed- or free-form source format
> on that basis I'm unaware any has done that???).
As far as I know, include files are included textually, such that
they have the same form (free or fixed) as the file into which
they are included.
If that is true, it is probably best to write them such
that they are valid in both forms. If I remember it right,
terminating & in column 73, and continuation & in column 6.
Or avoid continuations and keep within 72 columns.
-- glen
glen herrmannsfeldt
(actually, I wrote)
>> > It is common in C not to include executable statements in #include
>> > files, though the compiler doesn't care. Similar conventions might
>> > be useful in Fortran, too.
> No, because include files are used very differently in C than in
> fortran. In C, include files usually have declarations and macros
> that are shared by many programs to keep things consistent. Fortran
> has modules for that purpose. In fortran, include files are used
> for source code that is common to several different subroutines with
> different declarations, for example, the repetitive body of a
> subprogram compiled with different combinations of KIND parameters.
Well, include files came as an extension in many Fortran 66 compilers
(DEC at least), mostly for keeping declarations consistent.
It might even be that C adopted them from Fortran.
> I've written code where the multiple instances of a set of
> subroutines consisted ONLY of defining the KIND parameters (just one
> or two lines of code), and the include text contained the
> parameterized declarations of the variables and the subroutine body.
> That about as opposite to the C approach as you could possibly get.
I believe that has also been done in C. (Well, except for the KINDs.)
(snip)
Also, it might be that one would write the appropriate INCLUDE
file for C interoperability to match a C include file, declaring
the appropriate structures and functions.
> It is almost impossible to write C programs without using include
> files (header files). In fortran, you could write millions of lines
> of code and never need an include file. So however you think
> include files should be handled in fortran, it just isn't a big
> deal, and consequently it is unlikely to be changed in the future,
> particularly in a way that is incompatible with past conventions.
-- glen
glen herrmannsfeldt
(snip)
> Although, as noted in this thread, an include file has nothing to do
> with scoping unit boundaries, it does have to do with statement
> boundaries. You cannot continue a statement across a boundary either
> into or out of an include file.
I believe you can in C with #include, though I haven't
actually tried it.
-- glen
pwillis
>
> How so? I can't see any reason whatever that the file name for an
> INCLUDEd file couldn't be _any_ OS-consistent valid file name.
>
> The overall source file in which the INCLUDE statement resides will
> likely indicate free/fixed source format for most current compilers but
> that's totally separate from an include file.
Sorry, the compiler originally made no distinction.
The editor however doesn't do any syntax highlighting unless the file
has one of the predefined extensions associated with the FORTRAN
language.
The include code was put into a .f90 file as opposed to the original
'.txt' file
The compiler then complained at the compile of the include file:
"Error: Syntax error, found END-OF-FILE when expecting one of: <LABEL>
<END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE
CHARACTER ..."
Given that particular error a terminating 'end' placed at the bottom
of the file
resolves the issue, only to create the new 'scope' issues previously
described.
(for obvious reasons)
By renaming the file to <FILE_NAME>.fi, ('.fi' being one of the
extensions that allow FORTRAN syntax highlighting
in the editor) the compiler happly compiles the include file without
the terminating 'end' statement with no complaint.
So, the whole issue was caused by:
a.) a quest to get FORTRAN syntax highlighting of the include file in
the editor
b.) using an incorrect [??not really] file extension for an include
file to begin with to get syntax highlighting
c.) putting an 'end' statement at the bottom of the include file to
make the include file compile with the .f90 file extension.
The issue was resolved by:
a.) Maintaining FORTRAN syntax highlighting in the editor by using
'.fi' file extension
b.) Removing the 'end' statement from the bottom of the include file
Not having created the FORTRAN compiler myself, I really can't speak
as to *WHY* it
compiles files of different extensions in different ways.
Peter
Richard Maine
> The include code was put into a .f90 file as opposed to the original
> '.txt' file
> The compiler then complained at the compile of the include file:
> "Error: Syntax error, found END-OF-FILE when expecting one of: <LABEL>
> <END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE
> CHARACTER ..."
...
> c.) putting an 'end' statement at the bottom of the include file to
> make the include file compile with the .f90 file extension.
That sounds (very much) like an incorrect diagnosis. Having an END
statement has zero to do with the file extension - I repeat zero.
Instead, it sounds like the issue I mentioned earlier. Probably you (or
some system you used) tried to compile all files named *.f90. You aren't
supposed to compile an include file. Doing so will not work (unless the
include file happens to consist of entire program units, which is rare,
though not unheard of - it is not the case here). The include file is
only used as part of compiling some other file - not as something you
compile separately on its own.
Changing the extension of an include file will not change whether it
sucessfully compiles or not (ignoring fixed vs free form issues, which
are not the issue here). If you think it changed that, then I'd bet
quite strongly that you are misunderstanding what is happening.
If you do anything that tries to compile all the .f90 files, then
changing the extension will appear to fix the problem, but that's not
because the file then compiles correctly, but because you don't try to
compile it at all.
dpb
...
> Although, as noted in this thread, an include file has nothing to do
> with scoping unit boundaries, it does have to do with statement
> boundaries. You cannot continue a statement across a boundary either
> into or out of an include file.
That that wouldn't be so has never crossed my thought horizon and doubt
it ever would have... :)
--
Ron Shepard
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
Since we are pontificating on various include quirks, there is another
one that might be worth mentioning here. This is the case where the
include file text contains preprocessor directives. If it is included
with fortran INCLUDE, then some compiler+preprocessor combinations do
not preprocess that text afterwards, but if the file is included with
#include, then it is preprocessed (recursively, if necessary). It is
easy to understand why this might be the case, but if the C preprocessor
directives were actually part of the fortran standard (the way they
should be, for the past 20 years), it would almost certainly be
otherwise.
$.02 -Ron Shepard
nm...@cam.ac.uk
Ron Shepard <ron-s...@NOSPAM.comcast.net> wrote:
>
>Since we are pontificating on various include quirks, there is another
>one that might be worth mentioning here. This is the case where the
>include file text contains preprocessor directives. If it is included
>with fortran INCLUDE, then some compiler+preprocessor combinations do
>not preprocess that text afterwards, but if the file is included with
>#include, then it is preprocessed (recursively, if necessary). It is
>easy to understand why this might be the case, but if the C preprocessor
>directives were actually part of the fortran standard (the way they
>should be, for the past 20 years), it would almost certainly be
>otherwise.
Er, I think that you need to find out more about the specification
and practical behaviour of those monstrosities. Even within C, they
are a gibbering nightmare. Several people (Bjarne included, if I
recall) tried to get them excluded from C++, but unfortunately failed.
One of the reasons that WG14 leaves their specification ambiguous
is that there is no way to specify them precisely without causing
an unknown amount of chaos. Yes, they ARE that bad.
Regards,
Nick Maclaren.
glen herrmannsfeldt
(snip on recursion and include)
> Er, I think that you need to find out more about the specification
> and practical behaviour of those monstrosities. Even within C, they
> are a gibbering nightmare. Several people (Bjarne included, if I
> recall) tried to get them excluded from C++, but unfortunately failed.
> One of the reasons that WG14 leaves their specification ambiguous
> is that there is no way to specify them precisely without causing
> an unknown amount of chaos. Yes, they ARE that bad.
One that I saw once, that seemed to work with one compiler
but I am pretty sure isn't standard, is preprocessor directives
in replacement text.
#define x define
#x y 1
I don't think that was the exact example, but it did have
to do with the replaced text as preprocessor input.
-- glen
glen herrmannsfeldt
> pwillis <silliw...@gmail.com> wrote:
>> The include code was put into a .f90 file as opposed to the original
>> '.txt' file
>> The compiler then complained at the compile of the include file:
>> "Error: Syntax error, found END-OF-FILE when expecting one of: <LABEL>
>> <END-OF-STATEMENT> ; BLOCK BLOCKDATA PROGRAM TYPE COMPLEX BYTE
>> CHARACTER ..."
> ...
>> c.) putting an 'end' statement at the bottom of the include file to
>> make the include file compile with the .f90 file extension.
> That sounds (very much) like an incorrect diagnosis. Having an END
> statement has zero to do with the file extension - I repeat zero.
> Instead, it sounds like the issue I mentioned earlier. Probably you (or
> some system you used) tried to compile all files named *.f90.
That could be, but it might be that some other errors could cause
similar messages.
What happens if there are statements before the PROGRAM statement?
-- glen
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
>
> > That sounds (very much) like an incorrect diagnosis. Having an END
> > statement has zero to do with the file extension - I repeat zero.
>
> > Instead, it sounds like the issue I mentioned earlier. Probably you (or
> > some system you used) tried to compile all files named *.f90.
> (snip)
>
> That could be, but it might be that some other errors could cause
> similar messages.
>
> What happens if there are statements before the PROGRAM statement?
That would have nothing to do with the file name.
Ron Shepard
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> What happens if there are statements before the PROGRAM statement?
Presumably those would be comment statements, and they would be
associated with the program. If they occur before a SUBROUTINE or a
FUNCTION statement, the same thing, they are associated with that
subprogram. Not all utilities got that right. I've used versions
of the fsplit utility, for example, that would put comments that
occurred in between and END and the following SUBROUTINE statement
in the wrong file. I don't have the standard with me to check, but
I'm pretty sure this was set in f77.
$.02 -Ron Shepard
glen herrmannsfeldt
(snip, I wrote)
>> What happens if there are statements before the PROGRAM statement?
> Presumably those would be comment statements, and they would be
> associated with the program. If they occur before a SUBROUTINE or a
> FUNCTION statement, the same thing, they are associated with that
> subprogram.
I meant non-comments, such as declarations.
I tried it with gfortran and got:
Error: Unexpected PROGRAM statement at (1)
For the test program:
integer x(5)
program this
integer y(6)
y=3
print *,y
end
I don't know that is especially obvious.
I might have expected something about a missing END statement.
-- glen
Richard Maine
> In article <i56uht$hpd$2...@speranza.aioe.org>,
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
> > What happens if there are statements before the PROGRAM statement?
>
> Presumably those would be comment statements,
Note that there is no such thing as a "comment statement." Comments are
not statements. Yes, it makes a difference because comments don't follow
any of the rules for statements. If they were statements, they could
have continuations, statement labels, and other behavior that they don't
have. There were just comment lines in f66 and f77. (F90 added the
previously nonstandard, but widely used trailing comments on a line, but
they still aren't statements.)
> and they would be
> associated with the program. If they occur before a SUBROUTINE or a
> FUNCTION statement, the same thing, they are associated with that
> subprogram. Not all utilities got that right. I've used versions
> of the fsplit utility, for example, that would put comments that
> occurred in between and END and the following SUBROUTINE statement
> in the wrong file. I don't have the standard with me to check, but
> I'm pretty sure this was set in f77.
I used compilers that got it "wrong", except that one probably could not
technically call it a bug in standard conformance because it didn't make
the program execute incorrectly. It just messed up the listings, putting
the comments after the end of the preceeding program unit instead of at
the beginning of the following one.
Because of this annoyance, I used to be in the habit of putting comments
after the initial statement of a program unit, even though I might have
thought them more appropriate before it.
I did just check the standard because I couldn't recall whether it was
the compilers or the standard that were "messed up" (to my thinking).
The f77 standard makes it very explicit that the END line is the last
line of a program unit. And it does say the last line - not just the
last sttement, so that means no comment lines could follow. It also
explicitly says that comment lines can precede the first statement. So
the standard agrees with my notion of sensibility on that; guess it was
just the compilers I remember that were "wrong." I also checked the f66
standard. It doesn't seem quite as explicit to me, but I think it says
the same thing. I don't see the bit explicitly saying that comments
before the initial statement are ok, but it does seem implicit.
However, as I noted in my previous post, none of this is plausibly
related to the OP's claim that changing the file extension changed the
compiler behavior. Yes, it is known to sometimes change compiler
behavior in terms of free versus fixed source, but no free vs fixed
source issues are evident anywhere in this thread.
Richard Maine
> I tried it with gfortran and got:
>
> Error: Unexpected PROGRAM statement at (1)
>
> For the test program:
>
> integer x(5)
> program this
> integer y(6)
> y=3
> print *,y
> end
>
> I don't know that is especially obvious.
> I might have expected something about a missing END statement.
I don't know why that would be any more obvious than the message it
gave. When one finds and END statement instead of a PROGRAM statement, I
don't see how it is more obvious to complain about what one didn't find
instead of what one did. I'm confident that people could misunderstand
either one. In fact, I'm quite sure that if it complained about a
missing END statement, there would be people who would be confused
because they see that there is so an END statement (not realizing that
it needs 2 of them).
And in some sense I could argue that the error had a lot more to do with
the presence of the program statement. After all, it isn't as if an END
statement has to follow the integer declaration. Lots of kinds of
statements could follow that. A program statement just isn't one of the
ones that can.
Maybe if it got long-winded enough to say both - that there has to be an
END statement before the next program statement. But then, as confusing
error messages go, I can't say any of this is very high on the list.
Some error messages can be very confusing, even to pretty experienced
programers. I'd say that if anyone got very confused by this one, they
must be a pretty novice Fortran user. And if even a novice stayed
confused by it for long enoug hto be a big deal, maybe that would be a
sign of bigger problems than could be solved by rewording the error
message.
glen herrmannsfeldt
(snip, I wrote)
>> I tried it with gfortran and got:
>> Error: Unexpected PROGRAM statement at (1)
(snip)
>> I don't know that is especially obvious.
>> I might have expected something about a missing END statement.
> I don't know why that would be any more obvious than the message it
> gave. When one finds and END statement instead of a PROGRAM statement, I
> don't see how it is more obvious to complain about what one didn't find
> instead of what one did.
Yes, it is just about as obvious, or not, either way.
> I'm confident that people could misunderstand
> either one. In fact, I'm quite sure that if it complained about a
> missing END statement, there would be people who would be confused
> because they see that there is so an END statement (not realizing that
> it needs 2 of them).
(snip)
> Maybe if it got long-winded enough to say both - that there has to be an
> END statement before the next program statement. But then, as confusing
> error messages go, I can't say any of this is very high on the list.
Somehow it reminds me of some of the messages from the IBM PL/I (F)
compiler, from around 1965 or so. In order to get the most
debugging from one run, it attempts to 'correct' errors and keep
going as much as possible. There are messages like:
Missing END statement, one inserted.
Missing semicolon, one inserted.
Well, first the inserted statement is in the internal copy of
the program, not the source on disk or cards. (And of course
the messages are all upper case.)
It will go on trying to fix up the program for as long as it
reasonably can. Sometimes the new errors are the result of
the previous fix being wrong.
Then, depending on the JCL parameters, it may or may not
try to run the result.
Oh well.
-- glen
glen herrmannsfeldt
(snip)
> not statements. Yes, it makes a difference because comments don't follow
> any of the rules for statements.
> I used compilers that got it "wrong", except that one probably could not
> technically call it a bug in standard conformance because it didn't make
> the program execute incorrectly. It just messed up the listings, putting
> the comments after the end of the preceeding program unit instead of at
> the beginning of the following one.
> Because of this annoyance, I used to be in the habit of putting comments
> after the initial statement of a program unit, even though I might have
> thought them more appropriate before it.
> I did just check the standard because I couldn't recall whether it was
> the compilers or the standard that were "messed up" (to my thinking).
> The f77 standard makes it very explicit that the END line is the last
> line of a program unit.
There are some interesting rules that result from that requirement.
One is that you aren't allowed to continue an END statement.
(I tried it once on VAX before I knew that rule. It worked, too.)
The other is that the initial line before a continuation can't
look like an END statement.
END
*=3
Compilers I used to know, when finding comments after the END,
would start compiling the next program unit. The resulting
errors are pretty strange, with at some point the missing END
statement message, and finally, from the linker, the message
about two MAIN programs.
> And it does say the last line - not just the
> last sttement, so that means no comment lines could follow. It also
> explicitly says that comment lines can precede the first statement. So
> the standard agrees with my notion of sensibility on that; guess it was
> just the compilers I remember that were "wrong." I also checked the f66
> standard. It doesn't seem quite as explicit to me, but I think it says
> the same thing. I don't see the bit explicitly saying that comments
> before the initial statement are ok, but it does seem implicit.
3.2.2 End Line. An end line is a line with the character
blank in columns 1 through 6, the characters E, N, and D, once
each and in that order, in columns 7 through 72, preceeded by,
interspersed with, or followed by the character blank. The end
line indicates to the processor the end of the written description
of a program unit (9.1.7). Every program unit must physically
terminate with an end line.
> However, as I noted in my previous post, none of this is plausibly
> related to the OP's claim that changing the file extension changed the
> compiler behavior. Yes, it is known to sometimes change compiler
> behavior in terms of free versus fixed source, but no free vs fixed
> source issues are evident anywhere in this thread.
No, but he also added the extra END statement, possibly due to
misunderstanding a message.
-- glen
nm...@cam.ac.uk
glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>Richard Maine <nos...@see.signature> wrote:
>
>> Note that there is no such thing as a "comment statement." Comments are
>> not statements. Yes, it makes a difference because comments don't follow
>> any of the rules for statements.
>
>(snip on comments before or after a program unit)
This is a truly weird area of Fortran, as it is in most programming
languages. At least now Fortran has reached a stage of sanity (it
assuredly used to be pretty insane).
Regards,
Nick Maclaren.
robin
| dpb <no...@non.net> wrote:
| (snip on include file naming)
|
| > I wasn't _recommending_ other as a wise or good practice; simply trying
| > to make the point of what INCLUDE does and that the name wouldn't be
| > looked at by the compiler to determine characteristics of the file
| > (altho I guess it is possible that one could go so far as to implement
| > parsing to the point of interpreting fixed- or free-form source format
| > on that basis I'm unaware any has done that???).
|
| As far as I know, include files are included textually, such that
| they have the same form (free or fixed) as the file into which
| they are included.
|
| If that is true,
It is.
| it is probably best to write them such
| that they are valid in both forms.
It's best to use only one form, namely, free form.
| If I remember it right,
| terminating & in column 73, and continuation & in column 6.
|
| Or avoid continuations and keep within 72 columns.
It is possible to code in a single form that's compatible with both
free and fixed form source.
robin
news:f51a1fab-11f0-449c...@m17g2000prl.googlegroups.com...
>By renaming the file to <FILE_NAME>.fi, ('.fi' being one of the
>extensions that allow FORTRAN syntax highlighting
>in the editor)
Why not .INC, I wonder?
robin
| Ron Shepard <ron-s...@nospam.comcast.net> wrote:
| (snip, I wrote)
|
| >> What happens if there are statements before the PROGRAM statement?
|
| > Presumably those would be comment statements,
They would be comment lines, not statements.
|> and they would be
| > associated with the program. If they occur before a SUBROUTINE or a
| > FUNCTION statement, the same thing, they are associated with that
| > subprogram.
|
| I meant non-comments, such as declarations.
|
| I tried it with gfortran and got:
|
| Error: Unexpected PROGRAM statement at (1)
|
| For the test program:
|
| integer x(5)
| program this
| integer y(6)
| y=3
| print *,y
| end
|
| I don't know that is especially obvious.
| I might have expected something about a missing END statement.
There's no particular reason why it would do that.
The error message is appropriate.
robin
| Somehow it reminds me of some of the messages from the IBM PL/I (F)
| compiler, from around 1965 or so. In order to get the most
| debugging from one run, it attempts to 'correct' errors and keep
| going as much as possible. There are messages like:
|
| Missing END statement, one inserted.
This would only occur if the END statement for the entire program were
omitted.
| Missing semicolon, one inserted.
|
| Well, first the inserted statement is in the internal copy of
| the program, not the source on disk or cards. (And of course
| the messages are all upper case.)
|
| It will go on trying to fix up the program for as long as it
| reasonably can.
Most of the fixes were for trival errors.
| Sometimes the new errors are the result of
| the previous fix being wrong.
The "fix" was usually not wrong, because the fixes were for
trivial syntax errors, such as missing space, missing semicolon
(statement terminator), etc.
Gary L. Scott
> "pwillis"<silliw...@gmail.com> wrote in message
> news:f51a1fab-11f0-449c...@m17g2000prl.googlegroups.com...
>
>> By renaming the file to<FILE_NAME>.fi, ('.fi' being one of the
>> extensions that allow FORTRAN syntax highlighting
>> in the editor)
>
> Why not .INC, I wonder?
.fi stands for Fortran Include...I believe .inc was used for other
purposes commonly at the time
Dick Hendrickson
> "glen herrmannsfeldt"<g...@ugcs.caltech.edu> wrote in message news:i56e5s$mot$1...@speranza.aioe.org...
> | dpb<no...@non.net> wrote:
> | (snip on include file naming)
> |
> |> I wasn't _recommending_ other as a wise or good practice; simply trying
> |> to make the point of what INCLUDE does and that the name wouldn't be
> |> looked at by the compiler to determine characteristics of the file
> |> (altho I guess it is possible that one could go so far as to implement
> |> parsing to the point of interpreting fixed- or free-form source format
> |> on that basis I'm unaware any has done that???).
> |
> | As far as I know, include files are included textually, such that
> | they have the same form (free or fixed) as the file into which
> | they are included.
> |
> | If that is true,
>
> It is.
>
they textually replaced the INCLUDE statement. They will be treated
the same source form way as the rest of the program. There is no magic
that gives them the same source form as the rest of the file. The
programmer needs to get the source forms right.
Dick Hendrickson
Ron Shepard
Dick Hendrickson <dick.hen...@att.net> wrote:
> > | As far as I know, include files are included textually, such that
> > | they have the same form (free or fixed) as the file into which
> > | they are included.
> > |
> > | If that is true,
> >
> > It is.
> >
> This is potentially misleading. Include files are processed "as if"
> they textually replaced the INCLUDE statement. They will be treated
> the same source form way as the rest of the program. There is no magic
> that gives them the same source form as the rest of the file. The
> programmer needs to get the source forms right.
This is in contrast to modules where it is perfectly fine to USE a
module written in fixed-form source into a program that is written
in free-form source (and visa versa). Here the "magic" is indeed
done by the compiler.
$.02 -Ron Shepard
David Thompson
Ordinary syntax constructs in C (statements, declarations, blocks)
ignore line boundaries and can cross #include boundaries.
(IME for executable constructs compiled with debug info that may not
correctly identify sourcelines in the correct file. But debug info of
any kind, correct or not, isn't required by the standard.)
For preprocessor directives line boundaries do matter, and at least
notionally line continuation with backslash+EOL happens in phase 2
before preprocessor directives including #include in phase 4, so a
directive can't cross a boundary.
A directive (line) within a macro invocation is Undefined Behavior,
and IME trying to have macro invocations cross #include-end or even
caller-macro-end is unreliable. Now that C99 added _Pragma which is
sortof-function-like I'm not sure about it. And I'm not sure if
formally #if/#else/#endif should work across #include, but I've never
found a case where they would have done something I wanted.