"enddo" vs "end do" in do control structures
Jay Vee
I am relatively new to the language and noticed in a lot of literature
the terms "end do" and "enddo" are used (apparently) interchangeably.
What is the signifigance of the two forms, are they different? If so,
is there a historical reason for the distinction and which is the more
correct or appropriate to use?
Regards
JV
Erik Toussaint
N1830.pdf (the final draft of the Fortran 2008 standard) mentions the
following in section 3.3.2.2 Blank characters in free form, paragraph 3:
"One or more blanks shall be used to separate adjacent keywords except
in the following cases, where blanks are optional:
BLOCK DATA
END INTERFACE
DOUBLE PRECISION
END MODULE
ELSE IF
END PROCEDURE
ELSE WHERE
END PROGRAM
END ASSOCIATE
END SELECT
END BLOCK
END SUBMODULE
END BLOCK DATA
END SUBROUTINE
END CRITICAL
END TYPE
END DO
END WHERE
END ENUM
GO TO
END FILE
IN OUT
END FORALL
SELECT CASE
END FUNCTION
SELECT TYPE
END IF"
And it mentions the following in section 3.3.3.1 on fixed source form,
paragraph 2:
"Except in a character context, blanks are insigni cant and may be used
freely throughout the program."
So, in short, it's up to personal preference, or company policy, or
whatever, but it's interchangeable.
Erik.
nm...@cam.ac.uk
I enquired this at a J3 meeting. The two-word forms are preferable,
and some of the new keyword pairs do not have single word forms.
But what Erik Toussaint says is correct - they are equivalent, and
there is no plan to remove any of the forms.
Regards,
Nick Maclaren.
robin
You can use whichever you prefer.
I prefer "end do".
robin
The words are more readable when a blank is present.
>And it mentions the following in section 3.3.3.1 on fixed source form,
>paragraph 2:
>
>"Except in a character context, blanks are insigni cant and may be used
>freely throughout the program."
Fixed source form is error-prone, thus should be avoided.
JV
Dear all, thanks for the prompt responses and the standards
perspective, I will conform to the "correct" :) preferential way.
Regards
JV
Tim Prince
termination with a space, even in fixed source form. I just checked
with current compiler updates, and that restriction has been corrected.
--
Tim Prince
Dick Hendrickson
insignificant and it was reasonably common practice for people to spell
out two-word keywords. BLOCK DATA is easier on the eyes than BLOCKDATA.
With F1990 blanks became significant in the new free source form, but
remained insignificant in the old source form. As a way to easy the
transition, blanks were allowed in multi-word keywords at the natural
word breaks.
Dick Hendrickson
Phillip Helbig---undress to reply
<dick.hen...@att.net> writes:
> The historical reason is that back in the good old days blanks were
> insignificant and it was reasonably common practice for people to spell
> out two-word keywords. BLOCK DATA is easier on the eyes than BLOCKDATA.
> With F1990 blanks became significant in the new free source form, but
> remained insignificant in the old source form. As a way to easy the
> transition, blanks were allowed in multi-word keywords at the natural
> word breaks.
Right. And the reason blanks were insignificant is that they
corresponded to a column in a punch card in which no hole was punched.
So, in the event of a mistake, one could tape over it, making it a
blank, but it might be too fragile to re-punch it, so one carried on in
the next column.
glen herrmannsfeldt
The "historical reason" is that traditionally, and still in fixed
form Fortran, blanks are not significant. You can add them in
the middle of keywords, or remove them and make things completely
unreadable.
DO1I=1,10
1 WR I TE(*,*) I
ST
1OP
E N D
This feature was removed in free form, but special cases were
added for some common multi-word cases.
-- glen
glen herrmannsfeldt
(snip)
> The historical reason is that back in the good old days blanks were
> insignificant and it was reasonably common practice for people to spell
> out two-word keywords. BLOCK DATA is easier on the eyes than BLOCKDATA.
Note that PL/I, where blanks were always significant, allows
for both GO TO and GOTO. I don't remember any other two-word
cases, though.
> With F1990 blanks became significant in the new free source form, but
> remained insignificant in the old source form. As a way to easy the
> transition, blanks were allowed in multi-word keywords at the natural
> word breaks.
-- glen
Richard Maine
wrote:
> Right. And the reason blanks were insignificant is that they
> corresponded to a column in a punch card in which no hole was punched.
> So, in the event of a mistake, one could tape over it, making it a
> blank, but it might be too fragile to re-punch it, so one carried on in
> the next column.
I never did that one, or knew anyone who did. I'm not entirely convinced
that was the reason for blank insignificance. I suppose it is possible,
but I'm not convinced. Do you have positive information about this being
the reason, or is it just conjecture?
I don't think I'd have wanted to feed such a taped card through a
high-speed card reader. In fact, I rather strongly suspect I might have
gotten some pretty nasty looks from the computer operators if I had
tried to give them a deck with such taping. Sounds like a way to jam up
the reader.
What I have done is delete rows in paper tape. In that case, it is the
opposite. All the holes on a row punched counted as deleting the row
(not leaving a blank - just deleting it). No tape required.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de>
>wrote:
>
>> Right. And the reason blanks were insignificant is that they
>> corresponded to a column in a punch card in which no hole was punched.
>> So, in the event of a mistake, one could tape over it, making it a
>> blank, but it might be too fragile to re-punch it, so one carried on in
>> the next column.
>
>I never did that one, or knew anyone who did. I'm not entirely convinced
>that was the reason for blank insignificance. I suppose it is possible,
>but I'm not convinced. Do you have positive information about this being
>the reason, or is it just conjecture?
I never heard of that one, either. While some keypunch operators
were prone to inserting spurious spaces, I am pretty sure that the
reason was to allow code like the following:
PI BY 4 = 0.7853 9816 3397
or at least the latter. Allowing numbers with embedded spaces was
a near-universal convention in tables, and was allowed in some
pre-Fortran languages, as far as I recall. It assuredly was in
many input routines that were callable from machine code, for
very good reasons.
On this matter, why on earth do those bozos who write ATM software
and Web purchasing forms not allow spaces in card numbers? Dammit,
the CARDS have the spaces on them! It's not exactly innovation :-(
>I don't think I'd have wanted to feed such a taped card through a
>high-speed card reader. In fact, I rather strongly suspect I might have
>gotten some pretty nasty looks from the computer operators if I had
>tried to give them a deck with such taping. Sounds like a way to jam up
>the reader.
And how, even on an IBM reader - ICL readers had a shuffle-and-deal
feature at the best of times, and tatty cards tended to produce papier
mache of up to a dozen or so cards.
>What I have done is delete rows in paper tape. In that case, it is the
>opposite. All the holes on a row punched counted as deleting the row
>(not leaving a blank - just deleting it). No tape required.
Yup :-)
Regards,
Nick Maclaren.
Phillip Helbig---undress to reply
nos...@see.signature (Richard Maine) writes:
> I never did that one, or knew anyone who did. I'm not entirely convinced
> that was the reason for blank insignificance. I suppose it is possible,
> but I'm not convinced. Do you have positive information about this being
> the reason, or is it just conjecture?
I think I once read it in c.l.f, so it must be true. :-)
I never worked with punched cards myself, though I have seen them and
have met people (only a few years older than myself) who did. (I did
start late, though, not having had anything to do with computers until I
was 26.)
glen herrmannsfeldt
> Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de>
>> corresponded to a column in a punch card in which no hole was punched.
>> So, in the event of a mistake, one could tape over it, making it a
>> blank, but it might be too fragile to re-punch it, so one carried on in
>> the next column.
> I never did that one, or knew anyone who did. I'm not entirely convinced
> that was the reason for blank insignificance. I suppose it is possible,
> but I'm not convinced. Do you have positive information about this being
> the reason, or is it just conjecture?
I don't believe I ever saw or knew about that for programming,
but I do remember seeing it for bank card receipts. It used to
be that credit card invoices were the shape of punched cards,
and then as part of the processing they actually were punched.
As it was the original with signature, a copy wasn't quite the
same.
> I don't think I'd have wanted to feed such a taped card through a
> high-speed card reader. In fact, I rather strongly suspect I might have
> gotten some pretty nasty looks from the computer operators if I had
> tried to give them a deck with such taping. Sounds like a way to jam up
> the reader.
Reminds me of one time someone put a leaf in my card deck. The
card reader pulls the card from the stack in the direction of
the top of the card, and then feeds it column one first through
the read head. The card and leaf went through the first step,
then the reader declared a misfeed. I opened the door in the
back, removed the leaf (while making sure no-one was looking)
then continued on.
I believe, though, that there was special tape designed for
that function. Red, so as to block (enough) light for optical
readers, and also electric brush readers. With the 029
keypunch it was possible to duplicate while inserting
characters. Duplicate up to the point of insertion, press
the original against the high friction (black) backing while
inserting new charecters, then continue the duplicate. That
stops the original card from moving, such that the insert works.
> What I have done is delete rows in paper tape. In that case, it is the
> opposite. All the holes on a row punched counted as deleting the row
> (not leaving a blank - just deleting it). No tape required.
The original use for the ASCII DEL character, before DEC started
using it as the backspace character. (Confusing to us ever since.)
-- glen
robin
>
>Right. And the reason blanks were insignificant is that they
>corresponded to a column in a punch card in which no hole was punched.
>So, in the event of a mistake, one could tape over it, making it a
>blank, but it might be too fragile to re-punch it, so one carried on in
>the next column.
Definitely NOT; a piece of tape on a punch card would cause a card crash.
The metal throat on the card reader was just a tad wider than the thickness of the card.
Thus any tape on the card in this vicinity would have jammed in the throat.
Another possible result could have been that the tape peeled off and ended up wrapped around
some part of the rotating machinery used to move the card thru the mechanism
of the card reader.
The not uncommon practice to correct a punch card was to plug the hole
with a "chip" from the bin of confetti from the card punch, and then to reproduce the card.
robin
>Dick Hendrickson <dick.hen...@att.net> wrote:
>(snip)
>
>> The historical reason is that back in the good old days blanks were
>> insignificant and it was reasonably common practice for people to spell
>> out two-word keywords. BLOCK DATA is easier on the eyes than BLOCKDATA.
>
>Note that PL/I, where blanks were always significant, allows
>for both GO TO and GOTO. I don't remember any other two-word
>cases, though.
There are DO WHILE and DO UNTIL. but these pairs cannot be combined into one word.
Phillip Helbig---undress to reply
<rob...@dodo.com.au> writes:
For compatibility, any keywords from Fortran 77 have to work without
spaces (at least in fixed-form source) while this restriction doesn't
exist for new features (like DO WHILE and DO UNTIL).
Richard Maine
> For compatibility, any keywords from Fortran 77 have to work without
> spaces (at least in fixed-form source) while this restriction doesn't
> exist for new features (like DO WHILE and DO UNTIL).
Fixed source form is an unrelated issue. Spaces are just irrelevant
there. But there is a particular list of keywords that allow spaces in
free source form as well.
Compatibility with fixed source form doesn't really dictate that. If
that were the issue, then it would have to be allowed, for example, to
spell CONTINUE as C O N T I N U E, which is something I have seen in
old fixed-source-form code. I think it was supposed to spread it out for
some kind of visual reason.
Phillip Helbig---undress to reply
nos...@see.signature (Richard Maine) writes:
> Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de>
> wrote:
>
> > For compatibility, any keywords from Fortran 77 have to work without
> > spaces (at least in fixed-form source) while this restriction doesn't
> > exist for new features (like DO WHILE and DO UNTIL).
>
> Fixed source form is an unrelated issue. Spaces are just irrelevant
> there. But there is a particular list of keywords that allow spaces in
> free source form as well.
Since spaces could be omitted in Fortran 77, old code could have ENDIF
(as well as END IF or, for that matter E ND I F). Thus, with Fortran
90, one couldn't require a space between "END" and "IF" (at least not in
fixed-form source) without breaking a lot of old code. However, with
stuff which didn't exist in Fortran 77, there was no reason not to
require a space. (It's late; maybe I'm confused.)
glen herrmannsfeldt
(snip)
> Since spaces could be omitted in Fortran 77, old code could have ENDIF
> (as well as END IF or, for that matter E ND I F). Thus, with Fortran
> 90, one couldn't require a space between "END" and "IF" (at least not in
> fixed-form source) without breaking a lot of old code. However, with
> stuff which didn't exist in Fortran 77, there was no reason not to
> require a space. (It's late; maybe I'm confused.)
I think so.
All the old ways still work in fixed form. Spaces anywhere or no
spaces at all. Even new Fortran 90 or later statements still
work without spaces in fixed form. (That might have made it
harder to add some of them.)
Since there was no free form in Fortran 77, there is no compatibility
problem there.
-- glen
Richard Maine
wrote:
> In article <1jwy12r.1a3cg511jxt4wyN%nos...@see.signature>,
> nos...@see.signature (Richard Maine) writes:
>
> > Phillip Helbig---undress to reply <hel...@astro.multiCLOTHESvax.de>
> > wrote:
> >
> > > For compatibility, any keywords from Fortran 77 have to work without
> > > spaces (at least in fixed-form source) while this restriction doesn't
> > > exist for new features (like DO WHILE and DO UNTIL).
> >
> > Fixed source form is an unrelated issue. Spaces are just irrelevant
> > there. But there is a particular list of keywords that allow spaces in
> > free source form as well.
>
> Since spaces could be omitted in Fortran 77, old code could have ENDIF
> (as well as END IF or, for that matter E ND I F). Thus, with Fortran
> 90, one couldn't require a space between "END" and "IF" (at least not in
> fixed-form source) without breaking a lot of old code. However, with
> stuff which didn't exist in Fortran 77, there was no reason not to
> require a space. (It's late; maybe I'm confused.)
Yes, I'm guessing you must be. I can't think of much more to elaborate
than to repeat my prior post. I don't think you understood it. The
matter has nothing to do with fixed source form. The fixed source form
rules did not change with f90 and later (other than to make it
obsolescent). The rule in question relates *ONLY* to free source form,
which does not have such a compatibility issue.
If you do insist on talking about fixed source form, then it is still
valid Fortran. People certainly can write DOWHILE or DOUNTIL in fixed
source form today. I wouldn't do it, but it is perfectly valid. Any
argument about needing to be compatible with old code in fixed source
form would apply just as well to new code in fixed source form. If you
want to caim that somehow the fixed source form issues of DOWHILE are
any different from those of ENDDO, I just don't buy it. (One might also
note that DO WHile and END DO came into the standard at the same time,
which further argues against a distinction on that basis.)
Look at the actual list in the standard of keywords with optional
blanks. It isn't consistent at all with this argument. Heck. *MOST* of
the things in the list are ones that were added in f90 and later. One is
new to f2008 (if you look at the version of the list in the f2008
standard).
And again, I don't recall hearing anyone involved make arguments like
that. I just hear you speculating that this might have been the reason.
Admitedly, it can at times be hard to definitively state the reason for
some things even when one was there for the vote. Neither of us was
there for this one. But I just don't buy it.
robin
I was replying to Glen's comment about PL/I.
In PL/I, there are DO WHILE and DO UNTIL,
glen herrmannsfeldt
(snip)
> There are DO WHILE and DO UNTIL. but these pairs cannot be
> combined into one word.
No, it is the WHILE option to the DO statement. There are a
large number of other statements with keyword options that also
can't appear as one word.
GET DATA, GET LIST, GET EDIT, GET FILE, GET STRING,
the same with PUT, then READ and WRITE have many options,
along with many other statements.
GOTO is not the TO option of the GO statement.
-- glen
nm...@cam.ac.uk
Richard Maine <nos...@see.signature> wrote:
>
>If you do insist on talking about fixed source form, then it is still
>valid Fortran. People certainly can write DOWHILE or DOUNTIL in fixed
>source form today. I wouldn't do it, but it is perfectly valid. Any
Just as you can write DOW HILE or:
0D
1O
2W
3H
4I
5L
6E
>argument about needing to be compatible with old code in fixed source
>form would apply just as well to new code in fixed source form. If you
>want to caim that somehow the fixed source form issues of DOWHILE are
>any different from those of ENDDO, I just don't buy it. (One might also
>note that DO WHile and END DO came into the standard at the same time,
>which further argues against a distinction on that basis.)
I did have to read the relevant section more than once to convince
myself that the fixed/free form distinction was totally independent
of the rest of the syntax.
I used to use ENDDO, on the grounds that it was a keyword, but changed
when I found out that Fortran has adopted the concept of keyphrases,
as the preferred form.
Regards,
Nick Maclaren.
robin
>(snip)
>
>> There are DO WHILE and DO UNTIL. but these pairs cannot be
>> combined into one word.
>
>No, it is the WHILE option to the DO statement.
It may be an option, but it still can't be combined into one word.
Nor can DO FOREVER be combined into one word.
> There are a
>large number of other statements with keyword options that also
>can't appear as one word.
>
>GET DATA, GET LIST, GET EDIT, GET FILE, GET STRING,
>the same with PUT, then READ and WRITE have many options,
>along with many other statements.
>
>GOTO is not the TO option of the GO statement.
That's irrelevant.
The point is that adjacent PL/I keywords cannot be combined
onto one word (thank goodness).
Dan Stephenson
> BLOCK DATA is easier on the eyes than BLOCKDATA.
precendent, insists on naming everything with a initial lower case
followed by uppercase. Such as myRoutine or rungeKuttaExtrapolation.
Whose bright idea is that? I tell you, it causes me to pause and
interpret what is going on, since it doesn't follow the natural form of
language. My colleage doesn't seem to care, though.
--
Dan Stephenson
http://web.mac.com/stepheda
Travel pages for Europe and the U.S.A. (and New Zealand too)
Erik Toussaint
> On 2011-02-17 12:01:16 -0600, Dick Hendrickson said:
>
>> BLOCK DATA is easier on the eyes than BLOCKDATA.
>
> A colleage uses C++ a lot of apparently because of some Microsoft (?)
> precendent, insists on naming everything with a initial lower case
> followed by uppercase. Such as myRoutine or rungeKuttaExtrapolation.
>
> Whose bright idea is that? I tell you, it causes me to pause and
> interpret what is going on, since it doesn't follow the natural form of
> language. My colleage doesn't seem to care, though.
JWM
<stephed...@mac.com> wrote:
> On 2011-02-17 12:01:16 -0600, Dick Hendrickson said:
>
>> BLOCK DATA is easier on the eyes than BLOCKDATA.
>
> A colleage uses C++ a lot of apparently because of some Microsoft (?)
> precendent, insists on naming everything with a initial lower case
> followed by uppercase. Such as myRoutine or rungeKuttaExtrapolation.
>
> Whose bright idea is that? I tell you, it causes me to pause and
> interpret what is going on, since it doesn't follow the natural form of
> language. My colleage doesn't seem to care, though.
era: http://en.wikipedia.org/wiki/Hungarian_notation
Then there's the notation quite common in Java (and by extension, in C# ):
http://en.wikipedia.org/wiki/Naming_convention_(programming)#Java
As for the Java-like notation, I actually like the idea of using a verb
for the first part of a procedure's name.
--
John
Richard Maine
> As for the Java-like notation, I actually like the idea of using a verb
> for the first part of a procedure's name.
use a verb form for subroutines, but a noun form for functions. That's
because the basic concept of a subroutine is to do some action, while
the basic concept of a function is to have a result value. There is, of
course, overlap between those concepts. I think the English grammar of
the statements tend to read more naturally with that distinction.
Thus for example, if I want to compute "stuff", if I do it in a
subroutine, I might have something like
call compute_stuff(stuff, other_arguments)
but if I had it as a function, it is more likely to be
x = stuff(some_arguments)
Gib Bogle
> On 2011-02-17 12:01:16 -0600, Dick Hendrickson said:
>
>> BLOCK DATA is easier on the eyes than BLOCKDATA.
>
> A colleage uses C++ a lot of apparently because of some Microsoft (?)
> precendent, insists on naming everything with a initial lower case
> followed by uppercase. Such as myRoutine or rungeKuttaExtrapolation.
>
> Whose bright idea is that? I tell you, it causes me to pause and
> interpret what is going on, since it doesn't follow the natural form of
> language. My colleage doesn't seem to care, though.
sense that I should adopt SOME convention, but unfortunately the result
has been just to introduce more variations into my code, since I am not
consistent and can't be bothered going through all the existing code and
changing names.
While we are on the subject of aesthetics, I'm annoyed when I come
across code in which the writer apparently believes that a blank line
must be made into a comment (usually with initial 'C', since such code
is almost invariably all upper-case - another horrible thing to
encounter). I'm working with such a piece of code at the moment
(NLEQ1). I'd like to make it into f90, but there are a couple of
thousand comments and I don't have an easy foolproof method of
converting the 'C's to '!'s.
Richard Maine
> I'm working with such a piece of code at the moment
> (NLEQ1). I'd like to make it into f90, but there are a couple of
> thousand comments and I don't have an easy foolproof method of
> converting the 'C's to '!'s.
in column 1, and a C in column 1 always has that effect. This is, of
course, for fixed source form.
I don't know what editor you use, but with ones that support regular
expressions, it is usually pretty easy to specify that a pattern starts
in column 1.
Heck, one could write a Fortran program to do that part. I'm thinking
that
read(in_lun,'(a)') line
if (line(1:)=='c' .or. line(1:1)=='C') line(1:1) = '!'
write(out_lun,'(a)') line
ought to do the trick just fine, when wrapped in a suitable loop and a
few declarations.
Gib Bogle
> Gib Bogle<g.b...@auckland.ac.nz> wrote:
>
>> I'm working with such a piece of code at the moment
>> (NLEQ1). I'd like to make it into f90, but there are a couple of
>> thousand comments and I don't have an easy foolproof method of
>> converting the 'C's to '!'s.
>
> Being a C in column 1 should be a foolproof criterion. The C has to be
> in column 1, and a C in column 1 always has that effect. This is, of
> course, for fixed source form.
>
> I don't know what editor you use, but with ones that support regular
> expressions, it is usually pretty easy to specify that a pattern starts
> in column 1.
>
> Heck, one could write a Fortran program to do that part. I'm thinking
> that
>
> read(in_lun,'(a)') line
> if (line(1:)=='c' .or. line(1:1)=='C') line(1:1) = '!'
> write(out_lun,'(a)') line
>
> ought to do the trick just fine, when wrapped in a suitable loop and a
> few declarations.
>
Fortran program will suffice.
glen herrmannsfeldt
(snip)
> across code in which the writer apparently believes that a blank line
> must be made into a comment (usually with initial 'C', since such code
> is almost invariably all upper-case - another horrible thing to
> encounter). I'm working with such a piece of code at the moment
> (NLEQ1). I'd like to make it into f90, but there are a couple of
> thousand comments and I don't have an easy foolproof method of
> converting the 'C's to '!'s.
not until 90.
-- glen
glen herrmannsfeldt
> Gib Bogle <g.b...@auckland.ac.nz> wrote:
>> I'm working with such a piece of code at the moment
>> (NLEQ1). I'd like to make it into f90, but there are a couple of
>> thousand comments and I don't have an easy foolproof method of
>> converting the 'C's to '!'s.
> Being a C in column 1 should be a foolproof criterion. The C has to be
> in column 1, and a C in column 1 always has that effect. This is, of
> course, for fixed source form.
It might depend on the shell, the ! needs to be escaped for some,
which seems to work right with the quotes and backslash
-- glen
Rafik Zurob
> That seems to be the C/C++ convention. I've flirted with it, out of a
> sense that I should adopt SOME convention, but unfortunately the result
> has been just to introduce more variations into my code, since I am not
> consistent and can't be bothered going through all the existing code and
> changing names.
(http://www.eclipse.org/photran/), an open-source Eclipse-based IDE for
Fortran from the University of Illinois that comes with quite a few
refactorings, including style and FORTRAN to Fortran 90 ones. You can find
a list at
http://wiki.eclipse.org/PTP/photran/documentation/photran7advanced.
Unfortunately, it can only refactor free-form code at the present. So you'd
still have to use regular expressions as others suggested to convert
characters in column 1 into ! and characters in column 5 into & in the
previous line to convert fixed-form files into free-form ones.
Rafik
Gib Bogle
>
>> I'm working with such a piece of code at the moment
>> (NLEQ1). I'd like to make it into f90, but there are a couple of
>> thousand comments and I don't have an easy foolproof method of
>> converting the 'C's to '!'s.
>
> Being a C in column 1 should be a foolproof criterion. The C has to be
> in column 1, and a C in column 1 always has that effect. This is, of
> course, for fixed source form.
>
> I don't know what editor you use, but with ones that support regular
> expressions, it is usually pretty easy to specify that a pattern starts
> in column 1.
>
> Heck, one could write a Fortran program to do that part. I'm thinking
> that
>
> read(in_lun,'(a)') line
> if (line(1:)=='c' .or. line(1:1)=='C') line(1:1) = '!'
> write(out_lun,'(a)') line
>
> ought to do the trick just fine, when wrapped in a suitable loop and a
> few declarations.
>
required. There were other issues, some typical (some undeclared
variables, many column 6 continuation characters), and some resulting
from the move to modules (unwanted EXTERNAL statements). It now builds
as F90, but most of the code still starts in column 7, and there are
various other F77 relics like DO loops terminated by numbered CONTINUE
statements. These are just aesthetic issues, the main thing is that I
can USE it as a module.
Richard Maine
> As Richard suggested, a very simple Fortran program was all that was
> required. There were other issues, some typical (some undeclared
> variables, many column 6 continuation characters), and some resulting
> from the move to modules (unwanted EXTERNAL statements). It now builds
> as F90, but most of the code still starts in column 7, and there are
> various other F77 relics like DO loops terminated by numbered CONTINUE
> statements. These are just aesthetic issues, the main thing is that I
> can USE it as a module.
because it has been mentioned so many times in the past, and I assumed
you were aware of it, but sometimes my assumptions are wrong....
Being in fixed source form is *NOT* incompatible with being valid
Fortran 90 and being used as a module. You mention some aesthetic
issues, and I certainly agree that free source form has better
aesthetics. It can also be more convenient for various reasons, but none
of those have anything to do with being valid f90. In particular, yes,
you can have a module in fixed source form.
You very probably will run into confusions caused by the widespread use
of .f90 as a file name extension. But that file name extension does
*NOT* mean Fortran 90 (which makes it a pretty unfortunate choice of
name). It just means free source form. There are people who like to take
that extension as meaning Fortran 90, but that's not what it means to
compilers.
Gib Bogle
> I think I failed to mention it in this particular thread, largely
> because it has been mentioned so many times in the past, and I assumed
> you were aware of it, but sometimes my assumptions are wrong....
>
> Being in fixed source form is *NOT* incompatible with being valid
> Fortran 90 and being used as a module. You mention some aesthetic
> issues, and I certainly agree that free source form has better
> aesthetics. It can also be more convenient for various reasons, but none
> of those have anything to do with being valid f90. In particular, yes,
> you can have a module in fixed source form.
>
> You very probably will run into confusions caused by the widespread use
> of .f90 as a file name extension. But that file name extension does
> *NOT* mean Fortran 90 (which makes it a pretty unfortunate choice of
> name). It just means free source form. There are people who like to take
> that extension as meaning Fortran 90, but that's not what it means to
> compilers.
>
from compiling as .f90.
Ron Shepard
> I'm working with such a piece of code at the moment
> (NLEQ1). I'd like to make it into f90, but there are a couple of
> thousand comments and I don't have an easy foolproof method of
> converting the 'C's to '!'s.
free source form. There are several utilities out there that do
this. I use one called "freeform" which is a perl script. I don't
know exactly the source or the author, but I think it is from the
AMBER or CHARMM development communities. In any case, I've never
had any problems with it.
I think some of the regulars here in c.l.f have written similar
utilities, in fact some of them in fortran.
$.02 -Ron Shepard
glen herrmannsfeldt
>> Fortran 90 and being used as a module. You mention some aesthetic
>> issues, and I certainly agree that free source form has better
>> aesthetics. It can also be more convenient for various reasons, but none
>> of those have anything to do with being valid f90. In particular, yes,
>> you can have a module in fixed source form.
> from compiling as .f90.
thing incompatible with free form? Characters in 73-80 also would be,
but not so many do that now. (Maybe old code previously on
punched cards, and never changed since.)
There is a program that will convert fixed-from Fortran 77 code,
to free-form, but, at least last time I tried, would not
convert fixed-form Fortran 90 code.
-- glen
Gib Bogle
character ('$'). I changed those by hand. All done now.
dpb
...
>>> It was the 'C' as the comment character that was preventing this code
>>> from compiling as .f90.
That's _still_ the wrong interpretation of the .f90 extension--it's the
compiler thinking the files presented to it are in free- rather than
fixed-source form that's the problem, _not_ F90 (as in Standard level).
Use the proper compiler flag/switch for the files and nothing will be
needed to changed.
--
Gordon Sande
file extension. Some even have directives that can be mixed in with the source.
You might even be able to switch modes in the middle of a file in a few
exceptional
cases. To coin a phrase, RTFM! You never know what marvels you will find.
I believe their are several utilies that will change modes for you. They change
the commenting convention and sort out the continuations.
Richard Maine
> On 16/10/2011 6:32 p.m., Richard Maine wrote:
>
> > Being in fixed source form is *NOT* incompatible with being valid
> > Fortran 90 and being used as a module.
> > of .f90 as a file name extension. But that file name extension does
> > *NOT* mean Fortran 90 (which makes it a pretty unfortunate choice of
> > name). It just means free source form. There are people who like to take
> > that extension as meaning Fortran 90, but that's not what it means to
> > compilers.
> >
> It was the 'C' as the comment character that was preventing this code
> from compiling as .f90.
the confusion I was talking about. The C does not prevent it from being
compiled with a Fortran 90 compiler and it does not prevent it from
being compiled as a module. Either change the file name to have a .f
extension instead of .f90 (for most compilers) or use a compiler flag to
specify fixed source form, and the f90 compiler will compile it just
fine.
I'm not necessarily recomending leaving it in fixed source form. I'd
likely have converted it to free source form myself. But I just want to
clarify what is going on here. You referred to this process as
converting the code to f90, but that's not what it is. Instead, it is
converting the code to free source form.
As noted before, the unfortunate common choice of .f90 as a filename
extension for free source form encourages this confusion in that .f90
does not mean f90. It means free source form, which is only valid in f90
and later, but .f means fixed source form, which is also valid f90.
glen herrmannsfeldt
(snip)
> I'm not necessarily recomending leaving it in fixed source form. I'd
> likely have converted it to free source form myself. But I just want to
> clarify what is going on here. You referred to this process as
> converting the code to f90, but that's not what it is. Instead, it is
> converting the code to free source form.
to F90 (capital F). So it could be that some use f90, following
the extension convention, as short for free-form. (Add to the
confusion, the use of .F90 for preprocessed free-form.)
> As noted before, the unfortunate common choice of .f90 as a filename
> extension for free source form encourages this confusion in that .f90
> does not mean f90. It means free source form, which is only valid in f90
> and later, but .f means fixed source form, which is also valid f90.
likely too late even if one did.
-- glen
Richard Maine
> Richard Maine <nos...@see.signature> wrote:
> > As noted before, the unfortunate common choice of .f90 as a filename
> > extension for free source form encourages this confusion in that .f90
> > does not mean f90. It means free source form, which is only valid in f90
> > and later, but .f means fixed source form, which is also valid f90.
>
> So far, I haven't thought of a better extension, though, and it is
> likely too late even if one did.
top of my head, .ff would seem ok (for free-form fortran). Or I've seen
other ideas as well. But as you say, it is too late; I don't think
alternate suggestions are likely to catch on universally, even if they
seem good. I'd be happy to be shown wrong, though. I suppose it could
happen.
Gordon Sande
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
>
>> Richard Maine <nos...@see.signature> wrote:
>
>>> As noted before, the unfortunate common choice of .f90 as a filename
>>> extension for free source form encourages this confusion in that .f90
>>> does not mean f90. It means free source form, which is only valid in f90
>>> and later, but .f means fixed source form, which is also valid f90.
>>
>> So far, I haven't thought of a better extension, though, and it is
>> likely too late even if one did.
>
> I could easily come up with extensions that I'd think better. Off the
> top of my head, .ff would seem ok (for free-form fortran). Or I've seen
> other ideas as well. But as you say, it is too late; I don't think
> alternate suggestions are likely to catch on universally, even if they
> seem good. I'd be happy to be shown wrong, though. I suppose it could
> happen.
free form. Or is the other way around with all those leading f's?
How about .fxf ans .frf as something that would not work?
Gib Bogle
>> It was the 'C' as the comment character that was preventing this code
>> from compiling as .f90.
>
> Yes. But that C is just a feature of fixed source form. This is exavtly
> the confusion I was talking about. The C does not prevent it from being
> compiled with a Fortran 90 compiler and it does not prevent it from
> being compiled as a module. Either change the file name to have a .f
> extension instead of .f90 (for most compilers)
> or use a compiler flag to
> specify fixed source form, and the f90 compiler will compile it just
> fine.
specify fixed-form source. I might not have bothered to change the code
to free-form, since I don't anticipate having to make any changes to it.
I think this is in the growing category of things I once found out about
then forgot again.
glen herrmannsfeldt
(snip on confusing extensions for fixed form and free form fortran)
> free form. Or is the other way around with all those leading f's?
> How about .fxf ans .frf as something that would not work?
were usually three characters. (Three SIXBIT characters on 36 bit
systems, three RAD50 characters on 16 bit systems.) Some of the
extensions for Fortran were .FOR, .FTN, and, I believe, .F40.
It seems to me that Unix was the origin of popular one letter
extensions, with .f for Fortran source, .o for object programs, in
addition to the more obvious .c for C source programs. (And also
the origin of lower case extensions.)
IBM VM/CMS, which dates back pretty far, allows eight characters,
so Fortran source usually uses FORTRAN (no period is used).
CMS also uses the confusing TEXT extension for object programs,
and TXTLIB for object libraries. (The internal code in object
programs for actual code is TXT, as opposed to ESD (external symbol
dictionary) RLD (relocation dictionary) or END (hopefully obvious).
I do remember in the Fortran IV days, always rumors about the
new Fortran V that would arrive any day now, but never did.
Still, .f90 seems the obvious, even if obviously wrong, choice
at the time.
-- glen
Robin Vowels
> There is a program that will convert fixed-from Fortran 77 code,
> to free-form, but, at least last time I tried, would not
> convert fixed-form Fortran 90 code.
generally do not care what style of Fortran is there,
whether F77 or F90.
They are concerned only with treatment of comments and continuation
lines.
Robin Vowels
> I'm working with such a piece of code at the moment
> (NLEQ1). I'd like to make it into f90, but there are a couple of
> thousand comments and I don't have an easy foolproof method of
> converting the 'C's to '!'s.
However, there are tools that will do this job for you,
and that will handle continuation lines as well.
Robin Vowels
From: hel...@astro.multiCLOTHESvax.de (Phillip Helbig---undress to
reply)
Date: Thu, 17 Feb 2011 18:23:01 +0000 (UTC)
><dick.hendrick...@att.net> writes:
>> The historical reason is that back in the good old days blanks were
>> insignificant and it was reasonably common practice for people to spell
>> out two-word keywords. BLOCK DATA is easier on the eyes than BLOCKDATA.
>> With F1990 blanks became significant in the new free source form, but
>> remained insignificant in the old source form. As a way to easy the
>> transition, blanks were allowed in multi-word keywords at the natural
>> word breaks.
>Right. And the reason blanks were insignificant is that they
>corresponded to a column in a punch card in which no hole was punched.
>So, in the event of a mistake, one could tape over it, making it a
>blank, but it might be too fragile to re-punch it, so one carried on in
>the next column.
Tape was a no-no for punch cards.
If the tape was anywhere near the throat of the card reader,
the card would jam.
It was typical to plug up the hole(s) with a "chip",
and then to reproduce the card.
glen herrmannsfeldt
(snip)
> generally do not care what style of Fortran is there,
> whether F77 or F90.
but are in free form, the conversion needs to know the possible
keywords that could be put together without space, and where they
can occur. I learned this trying to convert fixed form Fortran 90
and had it fail. (Even though there were no cases of keywords
without the needed space.)
> They are concerned only with treatment of comments and continuation
> lines.
-- glen
Richard Maine
difference between fixed and free source form. Blank significance is
another difference. That difference affects more than just keywords. In
order to convert from fixed to free source form and do the whole job,
one actually needs to parse the code. Certainly there are many codes
where the job can be done much more simply than that, but those should
not be advertised as doing source form conversion unless they also come
with a caveat about only doing a subset of the conversion issues. It
might be a useful sebset, but it is a subset.
And regardless of what one might think "should" be so, some of the most
popular source form converters do, in fact, care because they do handle
blank significance. Metcalf's particularly comes to mind.
glen herrmannsfeldt
(snip)
> difference between fixed and free source form. Blank significance is
> another difference. That difference affects more than just keywords. In
> order to convert from fixed to free source form and do the whole job,
> one actually needs to parse the code. Certainly there are many codes
> where the job can be done much more simply than that, but those should
> not be advertised as doing source form conversion unless they also come
> with a caveat about only doing a subset of the conversion issues. It
> might be a useful sebset, but it is a subset.
I also have Fortran programs generated by other programs, though
which usually don't. (For fixed form, it is easier for the compiler,
as it has to be able to do it either way.)
> And regardless of what one might think "should" be so, some of the most
> popular source form converters do, in fact, care because they do handle
> blank significance. Metcalf's particularly comes to mind.
code that I tried.
-- glen
Richard Maine
> > difference between fixed and free source form. Blank significance is
> As most people actually do put in the blanks, it would be useful.
spelled spaced out as C O N T I N U E. And then there are things like
writing 1000000 as 1 000 000. Or people will use blanks to separate
words in their variable names.
Robert Miles
>
>> BLOCK DATA is easier on the eyes than BLOCKDATA.
>
> precendent, insists on naming everything with a initial lower case
> followed by uppercase. Such as myRoutine or rungeKuttaExtrapolation.
>
> Whose bright idea is that? I tell you, it causes me to pause and
> interpret what is going on, since it doesn't follow the natural form of
> language. My colleage doesn't seem to care, though.
I've seen that notation referred to as camelback.
Robin Vowels
wrote:
>
> (snip)
>
> > Programs that convert from fixed-form source to free-form source
> > generally do not care what style of Fortran is there,
> > whether F77 or F90.
>
> Wrong. Given that blanks are not significant in fixed form,
> but are in free form, the conversion needs to know the possible
> keywords that could be put together without space, and where they
> can occur. I learned this trying to convert fixed form Fortran 90
> and had it fail. (Even though there were no cases of keywords
> without the needed space.)
In a practical sense, none of the F77 and F90 programs that I have
converted
(and there are hundreds) experienced those dificulties.
In fact, to be strictly correct, you'd need to deal with spaces
anywhere
(except in character constants).
The biggest nuisance in converting old programs is not the blank
issue,
but Hollerith constants. That requires parsing FORMAT statements,
in particular.
Robin Vowels
> glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> > Richard Maine <nos...@see.signature> wrote:
>
> > > As you say, Glen, comments and continuation lines are not the only
> > > difference between fixed and free source form. Blank significance is
> > > another difference....
>
> > As most people actually do put in the blanks, it would be useful.
>
> Some people put in extra blanks. I have seen, for example, CONTINUE
> spelled spaced out as C O N T I N U E. And then there are things like
> writing 1000000 as 1 000 000. Or people will use blanks to separate
> words in their variable names.
in any of the hundreds of programs that I converted.
(And with 6-character names in F77, splitting individual words in
variable names
isn't anything I have ever seen.)
In the older programs, the issues were dealing with Hollerith
constants
and programming errors.