Fortran - My philosophy

Author

My philosophy

David Flower

2005-05-18, 8:57 am

I have been programming in FORTRAN since the summer of 1966, so I
thought that others might be interested in (or provoked by) my
programming philosophy. So here are some pointer themes.

1) Know the standard; many problems are caused simply by programmers
being unaware of the standard.

2) Even if a standard permits something, it is not necessarily good
practice; an example is neglecting to put a RETURN statement in a
sub-progam, letting the END statement do the work. This confuses two
themes (pass control to calling routine which is an executable
statement, and this is the last statement of this routine, which is
not), and suggests woolly thinking by the programmer.

3) Never use an extension when there is a perfectly satisfactory
standard method of doing something; on the same theme, don't use a
FORTRAN 90 peculiarity if you can do it equally well in FORTRAN 77.
Please understand, I am not saying don't use FORTRAN 90 constructs, I
am merely objecting to programmers who use such constructs to show how
clever they are, not to produce good code.

4) If you have to use extensions, try to encapsulate them; in the
future, some poor programmer is going to have to convert the program to
a compiler that does not support the extension, and would prefer to
have to modify one site in the program, not forty two. And that poor
programmer might be you!

5) In the past, programs usually had to be modified to minimise memory
and/or run time. Nowadays, most code should be optimised for
readability and maintainability. There are few FORTRAN statements more
essential than the comment statement.

Well, that should be enough to start a discussion!

glen herrmannsfeldt

2005-05-18, 8:57 am

David Flower wrote:

> I have been programming in FORTRAN since the summer of 1966, so I
> thought that others might be interested in (or provoked by) my
> programming philosophy. So here are some pointer themes.

(snip, pretty much agreeing)

> 5) In the past, programs usually had to be modified to minimise memory
> and/or run time. Nowadays, most code should be optimised for
> readability and maintainability. There are few FORTRAN statements more
> essential than the comment statement.

While minimizing memory use isn't so important, I don't believe it
is wise to unnecessarily waste memory.

As an example, if a program can process one line at a time and generate
the desired result, don't read the whole file in, process it, and write
the results out. There are cases where it is necessary,
and that is fine.

-- glen

Dick Russell

2005-05-18, 4:00 pm

Ah, soap box time. To the list of thoughts to keep in mind, add:

6) Put off coding until the programming is done. Do the programming at
some higher level of organization, outlining in some detail the
sequence of what must be done and methods used. Decide on the hierarchy
of subprograms, and produce documentation on how the whole thing and
each subprogram work. Debug at that level, then translate to code. If
you find that the last step is not just coding but involves too much in
the way or working out logic of events, then you need to go back up a
level to complete or revise the program. Spinning your wheels in trying
to get the code to cover all aspects of what possibilities must be
covered is a sure sign you haven't done the programming at a higher
level thoroughly yet. Fortran code shouldn't be the program, only the
compiler-readable form of the program.

RAR

beliavsky@aol.com

2005-05-18, 4:00 pm

David Flower wrote:
> I have been programming in FORTRAN since the summer of 1966, so I
> thought that others might be interested in (or provoked by) my
> programming philosophy. So here are some pointer themes.
> 1) Know the standard; many problems are caused simply by programmers
> being unaware of the standard.

Routinely compiling one's codes with several compilers and comparing
results helps one learn the standard.

> 2) Even if a standard permits something, it is not necessarily good
> practice; an example is neglecting to put a RETURN statement in a
> sub-progam, letting the END statement do the work. This confuses two
> themes (pass control to calling routine which is an executable
> statement, and this is the last statement of this routine, which is
> not), and suggests woolly thinking by the programmer.

What problems arise from not putting a RETURN statement before and END
statement?

> 3) Never use an extension when there is a perfectly satisfactory
> standard method of doing something; on the same theme, don't use a
> FORTRAN 90 peculiarity if you can do it equally well in FORTRAN 77.
> Please understand, I am not saying don't use FORTRAN 90 constructs, I
> am merely objecting to programmers who use such constructs to show
how
> clever they are, not to produce good code.

Can you cite a Fortran 90 construct that is overused?

Thanks for your comments.

<rest snipped>

Paul Van Delst

2005-05-18, 4:00 pm

Dick Hendrickson

2005-05-18, 4:00 pm

beliavsky@aol.com wrote:
> David Flower wrote:
>
>
>
> Routinely compiling one's codes with several compilers and comparing
> results helps one learn the standard.
Make sure that strict standards conformance, including
bounds checking and argument list matching, is turned on.

>
>
>
>
> What problems arise from not putting a RETURN statement before and END
> statement?
>
>
>
> how
>
>
>
> Can you cite a Fortran 90 construct that is overused?

Forcing things into array notation when simple DO
loops are clearer to the reader.

>
> Thanks for your comments.
>
> <rest snipped>
>

Dick Hendrickson

beliavsky@aol.com

2005-05-18, 4:00 pm

Dick Hendrickson wrote:
> beliavsky@aol.com wrote:

>
> Forcing things into array notation when simple DO
> loops are clearer to the reader.

I think element-wise array operations and intrinsic functions such as
DOT_PRODUCT, MATMUL, SUM, MINVAL, and PACK usually enhance readability
compared to loops, but I am wonder about complicated constructions
involving functions such as RESHAPE or SPREAD.

Richard E Maine

2005-05-18, 4:00 pm

In article
<yzJie.226112$cg1.101713@bgtnsc04-news.ops.worldnet.att.net>,
Dick Hendrickson <dick.hendrickson@att.net> wrote:

>
> Forcing things into array notation when simple DO
> loops are clearer to the reader.

Amen. In fact, this one is so overused (IMO) that you quite often hear
of people referring to this as converting from f77 to f90, as though the
DO loops somehow weren't valid f90, or even if valid, weren't "fully"
f90, or any of several other terms.

I'm a big "fan" of f90 as being an improvement over f77 (as any regular
reader of this newsgroup has probably figured out). But that doesn't
mean I am blind to issues like this. Not all f77 DO loops were
"broken", and thus they don't all need to be "fixed".

There are times when the array notation is a great improvement - better
clarity, faster, more robust, whatever. But there are other times when
it isn't, and some people seem to like to just go in with a simple
global rule, without actually bothering to evaluate individual cases.

Reminds me much of the old GOTO thing, where I have seen people take
perfectly clear, simple, and well-structured code, and turn it into a
mess because of an obsession with removing GOTOs in order to "improve"
the structure. Sometimes the mess is bad enough that they don't even
manage to get the translation right, introducing bugs.

By the way, I don't see anything in the OP's post that I'd disagree with.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Colin Watters

2005-05-18, 8:58 pm

Richard E Maine wrote:
> By the way, I don't see anything in the OP's post that I'd disagree with.

....Well *I* do.

David Flower wrote:
> 2) Even if a standard permits something, it is not necessarily good
> practice; an example is neglecting to put a RETURN statement in a
> sub-progam, letting the END statement do the work. This confuses two
> themes (pass control to calling routine which is an executable
> statement, and this is the last statement of this routine, which is
> not), and suggests woolly thinking by the programmer.

My preference is NO return statement. END should mean both these themes. In
the event that 2 or more RETURNS would otherwise be required, I prefer to
have a labelled CONTINUE immediately prior to the END, and GOTO it. I find
this useful in debugging, since you can set a breakpoint at the end of the
routine and know you will catch it at the point of RETURNing, so allowing
all local variables to be examined before they dissappear when the stack is
popped. IMHO multiple RETURNs is (are?) at least as bad as multiple entry
points (alas, a habit I am still trying to break!)
--
Qolin

Email: my qname at domain
Domain: qomputing dot demon dot co dot uk

Phillip Helbig---remove CLOTHES to reply

2005-05-20, 8:57 am

In article <1116416371.114554.258760@g47g2000cwa.googlegroups.com>,
"Dick Russell" <richard.russell@shawgrp.com> writes:

> Ah, soap box time. To the list of thoughts to keep in mind, add:
>
> 6) Put off coding until the programming is done. Do the programming at
> some higher level of organization, outlining in some detail the
> sequence of what must be done and methods used. Decide on the hierarchy
> of subprograms, and produce documentation on how the whole thing and
> each subprogram work. Debug at that level, then translate to code.

Right. As Jerry Leichter proclaimed in his First Law of Computing: "If
you don't know how to do it, you don't know how to do it on a computer".

David Flower

2005-05-20, 8:57 am

Well, you can equally have a labelled RETURN as a labelled continue.

David Flower

2005-05-20, 8:57 am

This is the ideal response to thr ideal scenario where the final
specification is known at the start of a project.

I do not, however, recognise it in my experience.

Most of my work has been in maintenance, not starting with a blank
sheet; final programs are often several times larger than the first
version.

I have often found that I am moving to a scenario where substantial
blocks of code are identical in several sub-programs, so a
restructuring is beneficial for future maintenance.

beliavsky@aol.com

2005-05-20, 8:57 am

Dick Russell wrote:
> Ah, soap box time. To the list of thoughts to keep in mind, add:
>
> 6) Put off coding until the programming is done. Do the programming
at
> some higher level of organization, outlining in some detail the
> sequence of what must be done and methods used. Decide on the
hierarchy
> of subprograms, and produce documentation on how the whole thing and
> each subprogram work. Debug at that level, then translate to code.

For programming that is done as part of research program, sometimes you
don't know exactly what the final code should look like or do. Getting
a small piece working on actual data may provide more guidance than the
planning done before programming. A written description of an algorithm
often uses pseudo-code. Actual code can be tested and debugged.

> If
> you find that the last step is not just coding but involves too much
in
> the way or working out logic of events, then you need to go back up a
> level to complete or revise the program. Spinning your wheels in
trying
> to get the code to cover all aspects of what possibilities must be
> covered is a sure sign you haven't done the programming at a higher
> level thoroughly yet. Fortran code shouldn't be the program, only the
> compiler-readable form of the program.

With features such as user-defined types, operator overloading, long
variable names, argument INTENT, array operations and intrinsic
functions, I think code in modern Fortran can be self-documenting to a
greater extent than in earlier versions. I describe the purpose of
every procedure and of the main program with a few comment lines at the
top, and document procedure arguments when their meaning is not
obvious. I usually don't have trouble understanding the programs I
wrote years ago.

I have wondered what comments (if any) to write at the beginning of a
module. I do list all procedures, variables, and derived types as
PUBLIC or PRIVATE. This list, along with the set of USE statements at
the top, give some idea of what algorithms are being implemented or
called.

Eric Lavigne

2005-05-20, 8:57 pm

>Reminds me much of the old GOTO thing, where I have seen people take
>perfectly clear, simple, and well-structured code, and turn it into a
>mess because of an obsession with removing GOTOs in order to "improve"
>the structure. Sometimes the mess is bad enough that they don't even
>manage to get the translation right, introducing bugs.

This is probably because I am new to FORTRAN, but I have yet to come
across code written with GOTOs that couldn't be more clearly written
with some other construct. Could anyone offer an example of perfectly
clear, simple, and well-structured code with GOTOs that isn't easily
translated into perfectly clear, simple, and well-structured code
without GOTOs? While I don't have anything in particular against GOTOs,
my own experience is that GOTOs tend to be a sign of sloppy
programming. They are a low-level programming tool, and FORTRAN 90 has
enough higher level tools to completely replace them.

Dick Hendrickson

2005-05-20, 8:57 pm

Eric Lavigne wrote:

>
>
> This is probably because I am new to FORTRAN, but I have yet to come
> across code written with GOTOs that couldn't be more clearly written
> with some other construct. Could anyone offer an example of perfectly
> clear, simple, and well-structured code with GOTOs that isn't easily
> translated into perfectly clear, simple, and well-structured code
> without GOTOs? While I don't have anything in particular against GOTOs,
> my own experience is that GOTOs tend to be a sign of sloppy
> programming. They are a low-level programming tool, and FORTRAN 90 has
> enough higher level tools to completely replace them.
>
Ah, "clear, simple, and well-structured" are sort of
judgment calls. Particularily the "simple" part when
applied to complex problems.

I think the best example is for error recovery. Data
is read in and processed via a longish series of loops,
constructs, whatever. If an error is detected, a GOTO
is a handy way to jump out of the main code flow and
process the error. It's not that you can't have an
IF-THEN-ELSE construct inside of every loop, it's
that it's sometimes harder to read code when the
error case code is intermixed in with the normal
case code. Especially if the error case code doesn't
do a fix-up and continue. If you need a series of
10 loops to do the processing, it's a pain in the butt
to have each enclosed in construct that skips the
loop if there was an error in the previous one.

Dick Hendrickson

Richard E Maine

2005-05-20, 8:57 pm

In article <1116618480.264789.302680@g14g2000cwa.googlegroups.com>,
"Eric Lavigne" <lavigne.eric@gmail.com> wrote:

> Could anyone offer an example of perfectly
> clear, simple, and well-structured code with GOTOs that isn't easily
> translated into perfectly clear, simple, and well-structured code
> without GOTOs?

Yes. But I really don't care to at the moment. (In spite of this
statement, I seem to have ended up pretty much doing it anyway below. Oh
well.) :-)

This is an old and often-discussed subject, which won't benefit from
rehashing. Plus, what one person sees as perfectly clear, simple, and
well-structured, a different person will see as a confusing,
complicated, poorly structured mess. The standards for these judgments
are not universal. There tends to be some commonality, but it is far
from universal.

The most commonly cited examples involve error handling. Indeed, that's
darned close to the only context in which I personally use GOTO these
days. I'd have to do a bit of searching to figure out when I last used a
GOTO for anything else in f90 code. Without bothering to write actual
code, I can summarize my typical use as

.... a bunch of code with multiple cases of "goto 8000"
.... don't ask me where I came up with 8000 because I forget,
.... but that's almost always the statement number I use for
.... my error exit. Yes, a named label would be clearer, but
.... we don't have those. The multiple gotos are at various
.... levels of depth in various structures. Yes, I'll claim
.... that the structures are otherwise "clean", but that's
.... not really relevant. You'll have to either believe me or
.... not or agree that it doesn't matter because I'm not
..... going to take the time to dig up a real sample.

!----- Normal exit
.... whatever I need for normal exits.
return

!----- Error exit
8000 continue !-- Yes, I always use a continue as the goto target.
!-- Almost the only place I ever use continue, by
!-- the way.
.... whatever I need for an error exit
.... likely to include error message output,
.... deallocations, and returning an error status.
.... enough that you won't want to replicate it for each
.... place where an error is detected.
return
end

You of course *CAN* translate this into something without goto. That was
proven long ago. One way is to set a variable to say you are in an error
state and make sure to put tests everywhere to skip over everything if
that variable is set. That gets to be quite a mess as you need tests at
many different levels. And I've seen people advocate new language
features for the purpose, but this discussion is about using the
language as it is - not about designing something else.

Probably the only thing I've seen that comes even close to being as
clean is an idea that I consider horribly error prone... and also not
quite as clean, but at least it is close. One of the F folk once
suggested it to me when I groused about the lack of goto in F (I think
they later broke down and added a goto with limitations that would allow
uses like this, because I'm sure I wasn't the only one to grouse).
Something like

some_label: do
.... the same bunch of code, but replace all cases of
.... "goto 8000" with "exit some_label"

!-- Normal exit
.... whatever
return
end do some_label

!--- Error exit
... whatever
return
end

I'll claim that the only benefit of this is cosmetic in that you can
make the some_label be more sensible-sounding than 8000. But the only
structural changes are negatives. We have introduced a completely bogus
infinite DO loop where no loop or other structure is really implied. It
is just a hack so that we can use an EXIT statement. The beginning point
of the loop has no meaning at all, but there has to be one somewhere
(and it has to be next right with any other structures). If you forget
the return before the "end do" statement, you just accidentally turned
the do loop into one that actually loops - and infinitely at that. If
you are going to tell me that changing the do statement to

some_label: do some_bogus_variable = 1 , 1

then I'll just go away quietly and conclude that we have very different
concepts of clean, simple, and well-structured. That's a lot of random
garbage to add on just to make sure that something that looks like a
loop doesn't actually act like one.

Oh. I've also seen a variant that uses an internal procedure. I don't
regard it as any cleaner either, and it adds some "issues" and
complications. Don't think I'll write it out now.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

beliavsky@aol.com

2005-05-20, 8:57 pm

Eric Lavigne wrote:
a[color=darkred]
"improve"[color=darkred]
>
> This is probably because I am new to FORTRAN, but I have yet to come
> across code written with GOTOs that couldn't be more clearly written
> with some other construct.

I thought so too until fairly recently, but the veterans here set me
straight :). The issue was discussed in the thread 'FORTRAN "Source
Code to Flow Chart Converter" Available' (search this newsgroup using
Google to find it), in which I asked a question very similar to yours.

Eric Lavigne

2005-05-20, 8:57 pm

>The most commonly cited examples involve error handling. Indeed,
that's
>darned close to the only context in which I personally use GOTO these
>days. I'd have to do a bit of searching to figure out when I last used
a
>GOTO for anything else in f90 code.

That does sound like a good use for it. It's fairly simple. Also, if
there's only one label, it's easy to remember the purpose of that label
when you run across "GOTO 8000"

>If you are going to tell me that changing the do statement to
> some_label: do some_bogus_variable = 1 , 1

Wow, that has got to be one of the ugliest tricks I've ever seen. I
like your solution better ^^ Have people seriously offered this as an
alternative to GOTOs?

Richard E Maine

2005-05-20, 8:57 pm

In article <1116630146.432564.270430@z14g2000cwz.googlegroups.com>,
"Eric Lavigne" <lavigne.eric@gmail.com> wrote:

>
> Wow, that has got to be one of the ugliest tricks I've ever seen.

I've seen worse. :-(

But then I've seen many things that tender eyes should not be exposed
to. I've probably even done worse, but I try to hide those skeletons.
See my signature. :-)

> Have people seriously offered this as an
> alternative to GOTOs?

I'm afraid so. Offered, yes. But I don't think they had very good luck
in getting it accepted.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

glen herrmannsfeldt

2005-05-21, 3:58 am

Richard E Maine wrote:
(snip)

(snip regarding uses for goto in structured programs)

> some_label: do
> .... the same bunch of code, but replace all cases of
> .... "goto 8000" with "exit some_label"
>
> !-- Normal exit
> .... whatever
> return
> end do some_label
>
> !--- Error exit
> ... whatever
> return
> end

> I'll claim that the only benefit of this is cosmetic in that you can
> make the some_label be more sensible-sounding than 8000. But the only
> structural changes are negatives.

C and PL/I have more descriptive alphanumeric labels, which helps some.
As I understand it PASCAL has numeric labels specifically to discourage
their use.

> We have introduced a completely bogus
> infinite DO loop where no loop or other structure is really implied. It
> is just a hack so that we can use an EXIT statement. The beginning point
> of the loop has no meaning at all, but there has to be one somewhere
> (and it has to be next right with any other structures). If you forget
> the return before the "end do" statement, you just accidentally turned
> the do loop into one that actually loops - and infinitely at that.

C has the do { } while(expression); statement, that is, with the
test at the end. This can be used for a do only once loop when you
didn't really want a loop by making the expression 0.

(It is sometimes used with the preprocessor for something that
can be used in place of a statement followed by a semicolon.)

PL/I's DO by default doesn't do any looping, but only grouping similar
to C's { and }.

C doesn't have a labeled form of break to exit more than one loop,
unlike Fortran's labeled EXIT or PL/I's LEAVE. Sometimes a goto
is better than multiple tests at the end of loops, and break statements
to exit the next level.

A PL/I labeled END will close more than one loop, a feature not
appreciated by people who like structured programming.

(snip)

-- glen

2005-05-21, 3:58 am

Eric Lavigne wrote:
>
> This is probably because I am new to FORTRAN, but I have yet to come
> across code written with GOTOs that couldn't be more clearly written
> with some other construct. Could anyone offer an example of perfectly
> clear, simple, and well-structured code with GOTOs that isn't easily
> translated into perfectly clear, simple, and well-structured code
> without GOTOs?

When we "was" new we thought often along the same lines for many
things, coding notwithstanding... now, you're on pg. 13 of the code
embellished with 13 endifs - was the sob so cleverly structured to match
the 7th endif with the if on pg.7? Maybe, but fonts has changed since
and you're still looking, counting up, counting down, going nowhere
fast.

Salvation, "deux ex machina", the wrath of the condemned, a *goto* that
sends you right where you want to go.

Michel OLAGNON

2005-05-21, 8:57 am

Richard E Maine wrote:

> .... a bunch of code with multiple cases of "goto 8000"
> .... don't ask me where I came up with 8000 because I forget,

I thought the number was supposed to be 7734, so that anyone
facing you can understand what you mean without any need for
turning the paper ;-)

Seriously, I also use Eight thousand for Error Exit, and
even Nine thousand for Normal Exit sometines.

Clive Page

2005-05-21, 3:56 pm

In message <1116618480.264789.302680@g14g2000cwa.googlegroups.com>, Eric
Lavigne <lavigne.eric@gmail.com> writes
>This is probably because I am new to FORTRAN, but I have yet to come
>across code written with GOTOs that couldn't be more clearly written
>with some other construct.

I tend to agree with you (though there are a few cases, such as
error-handling, where GOTOs are still handy).

One problem I've found with modern (i.e. free-format) Fortran is that
the code tends to start at or close to the left margin, so labels don't
stand out as well as they used to, when there were five columns in which
you couldn't put anything else (except comment text). Of course, one
can indent code to make the labels stand out visually, but lazy people
like me tend not to. So the odd label that persists tends to be even
more invisible to casual inspection than before, so that understanding a
bit of code after a few months becomes even more difficult. As a result
I tend to avoid using labels completely if I can.

--
Clive Page

kia

2005-05-22, 8:56 pm

Clive Page wrote:
>
> One problem I've found with modern (i.e. free-format) Fortran is that
> the code tends to start at or close to the left margin, so labels don't
> stand out as well as they used to, when there were five columns in which
> you couldn't put anything else (except comment text).

Probably what Backus had in mind when designing the look & feel; history
tends to teach us it's hard to improve on perfection.

> So the odd label that persists tends to be even
> more invisible to casual inspection than before, so that understanding a
> bit of code after a few months becomes even more difficult. As a result
> I tend to avoid using labels completely if I can.

Why not avoid free-form instead - a wiser choice. You could switch
latter if and when they start printing manuals in free form. As I
understand it they are both meant to be easy on the eye.

beliavsky@aol.com

2005-05-23, 3:58 pm

kia wrote:
> Clive Page wrote:
that[color=darkred]
don't[color=darkred]
which[color=darkred]
>
> Probably what Backus had in mind when designing the look & feel;
history
> tends to teach us it's hard to improve on perfection.

Backus later worked on Algol 60, which was a free form language. I
think he wrote in the 1960s that Algol was a better foundation for
future language development than FORTRAN.

Charles Russell

2005-05-25, 3:59 am

Richard E Maine wrote:
Yes, a named label would be clearer, but
> .... we don't have those.

Why not? Too simple to interest the standards committees?

Andy Spragg

2005-05-25, 8:57 am

On Fri, 20 May 2005 13:40:35 -0700, Richard E Maine
<nospam@see.signature> wrote:

>In article <1116618480.264789.302680@g14g2000cwa.googlegroups.com>,
> "Eric Lavigne" <lavigne.eric@gmail.com> wrote:
>

(snip)
[color=darkred]
>Probably the only thing I've seen that comes even close to being as
>clean is an idea that I consider horribly error prone... and also not
>quite as clean, but at least it is close. One of the F folk once
>suggested it to me when I groused about the lack of goto in F (I think
>they later broke down and added a goto with limitations that would allow
>uses like this, because I'm sure I wasn't the only one to grouse).
>Something like

(more snip)

I almost posted something like this a few days ago, having dreamed it
up for myself some time after I made the transition from 77 to 95 a
year or two ago. Except I think my version is not quite the same; the
basic rationale is to avoid multiple returns, something that cropped
up a w

or so ago, if not necessarily in this thread. The basic
template is:

do
! begin body of code, including however many
if (error_condition) exit
! end body of code
exit ! on normal completion
end do
! code to check for abnormal completions
return
end

As Richard pointed out, the obvious danger is that of the infinite
loop (I have fallen foul myself, and still do from time to time;). But
that danger is part and parcel of the do...end do construct (perhaps a
future revision of the standard might consider revising "do...end do"
to "do...exit; end do"?).

Gordon Sande

2005-05-25, 3:58 pm

Charles Russell wrote:
> Richard E Maine wrote:
> Yes, a named label would be clearer, but
>
>
>
> Why not? Too simple to interest the standards committees?

I got around to filling out the suggestion form at Fortran.com
and suggested construct names also act as statement labels.

My take is that it was a minor item that got lost in the big F90
revision. It should have been fixed in F95 but it took a bit longer
for it be be evident that it was an oversight that has turned out
to look worse and worse to more and more folks.

It is time to put the lie to those who ridicule Fortran for its
numeric statement labels. I.E. They are a prime source of bad PR.

More importantly for programmers they would allow better indication
of errors, etc. Labeling repeatedly used FORMATS would be nice also.

My suggestion is that the statement labels would require a following
colon to make fixed form source meaningful but that the colon would
be optional when it is redundant. The killer is

DO sam i = 1, 10
sam continue

vrs

DO sa mi = 1, 10
sa continue

but
do sam: i = 1, 10
sam: continue

seems to parse. They would not be in the label field so that existing
continuation rules would not be upset.

Richard E Maine

2005-05-25, 3:58 pm

In article <taRke.10838$lQ3.1934@bignews5.bellsouth.net>,
Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:

> Richard E Maine wrote:
> Yes, a named label would be clearer, but
>
> Why not? Too simple to interest the standards committees?

You left the smiley off of the second sentence. :-)

I assure you that simpler things than that have gotten attention.
Examples include such trivia as allowing a double colon for consistency
in EXTERNAL and INTRINSIC statements, or there was a similar trivial
syntax inconsistency in one form of END statement somewhere (I think it
was a END INTERFACE, but it isn't worth looking up). Those things are
truly trivial in that it takes about 5 seconds to deduce that they have
no possible complications.

There are actually technical issues with named labels - not difficult
ones, but certainly bigger than the two items I mentioned in the above
para. As Gordon mentioned, you need to do something or they don't parse
in free source form. Putting a colon after them might be adequate. Fixed
source form has a different issue; you probably need to say that they
have to start in column 2 or later - or do something else to avoid
conflicts with comments. And you have to check that parsing still works
everywhere that labels can be referenced; might be ok, but needs
checking. These aren't big issues, but they actually do require
decisions to be made.

Anyway, I can't give any better answer than the usual - didn't get
sufficient support. As noted above, the work, though small, isn't zero.
Apparently the amount of support was smaller than the work. Any other
reason would be purely speculative.

One such pure speculation on my part would be that statement labels are
too little used in new code to be worth fiddling with. Although I noted
earlier in this thread that I personally use statement labels, I also
noted that my use of them is extremely limited. A named label would be
an improvement for me, but so small as to not be worth much. When
presented with a list of more proposals than can reasonably be done, it
is very easy for that one to drop off the bottom. I suspect that there
are a lot of people in fairly close positions to mine - maybe using
statement labels slightly more or slightly less than I do, but in any
case not using them much. Some other people no doubt take a harder line,
avoiding statement labels completely.

And then there is probably a camp that thinks things are just fine as is
and we should stop fiddling with the language. To push for improvements
in statement labels, you probably need someone more "in the middle" -
conservative enough to think that statement labels have enough uses to
be worth fiddling with, but not so conservative that they don't want to
fiddle with anything.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

David Flower

2005-05-25, 3:58 pm

If I remember correctly, on Encore Concept machines, sam:i was a legal
variable name

Andy Spragg

2005-05-25, 3:58 pm

On Sat, 21 May 2005 17:42:28 +0100, Clive Page <junk@page.demon.co.uk>
wrote:

>In message <1116618480.264789.302680@g14g2000cwa.googlegroups.com>, Eric
>Lavigne <lavigne.eric@gmail.com> writes

[color=darkred]
>I tend to agree with you (though there are a few cases, such as
>error-handling, where GOTOs are still handy).

I tend to agree too, both ways e.g. how is it possible to write:

read (5, *, err = 999)

with some other construct? I know it's not an explicit GOTO, but it
only avoids being one by virtue of being built in to the foundations
;-)

Richard E Maine

2005-05-25, 3:58 pm

In article <1117037674. 8258ead9fa66707ab3264fd4e511e1b2@teranew
s>,
andy.spragg@rhm.com (Andy Spragg) wrote:

> how is it possible to write:
>
> read (5, *, err = 999)
>
> with some other construct?

By using iostat= instead of err=.

Whether that is preferable or not is another question. I have dropped
err= (along with end=, and I prety much never used eor=) from my
personal choice subset, but other people differ.

I mostly posted just to answer the question rather than to advocate any
position.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Charles Russell

2005-05-25, 8:57 pm

Richard E Maine wrote:

> You left the smiley off of the second sentence. :-)
>
Sorry. Here is my first smiley ever :-). There was no intent to be
impolite, but I learned English before the smiley era. and one of my
policies is to keep I/O as primitive as possible.

Gary L. Scott

2005-05-25, 8:57 pm

Richard E Maine wrote:

> In article <taRke.10838$lQ3.1934@bignews5.bellsouth.net>,
> Charles Russell <SPAMworFREEwor@bellsouth.net> wrote:
>
>
>
>
> You left the smiley off of the second sentence. :-)
>
>
> There are actually technical issues with named labels - not difficult
> ones, but certainly bigger than the two items I mentioned in the above
> para. As Gordon mentioned, you need to do something or they don't parse
> in free source form. Putting a colon after them might be adequate. Fixed
> source form has a different issue; you probably need to say that they
> have to start in column 2 or later - or do something else to avoid
> conflicts with comments. And you have to check that parsing still works
> everywhere that labels can be referenced; might be ok, but needs
> checking. These aren't big issues, but they actually do require
> decisions to be made.
I would have thought that starting with a colon would be better so that
anything
with a colon ending in space would be a label (no spaces in labels).
I'm pretty sure I've seen that style of label before

:label

Are there parse issues with that?

>

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Richard E Maine

2005-05-25, 8:57 pm

In article <1199vgoq509m1a@corp.supernews.com>,
"Gary L. Scott" <garyscott@ev1.net> wrote:

> I would have thought that starting with a colon would be better so that
> anything
> with a colon ending in space would be a label (no spaces in labels).
> I'm pretty sure I've seen that style of label before
>
>
> :label
>
> Are there parse issues with that?

There certainly are in fixed source form, where spaces aren't
significant. Of course, one could make the rules different for fixed
source form, but that's a complication.

(Or one could just blow off fixed source form, which wouldn't bother me
much, but then you've got a bigger debate with some people.)

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Richard E Maine

2005-05-25, 8:57 pm

In article <nospam-9C98FF.15442025052005@news.supernews.com>,
Richard E Maine <nospam@see.signature> wrote:

> In article <1199vgoq509m1a@corp.supernews.com>,
> "Gary L. Scott" <garyscott@ev1.net> wrote:
>
>
> There certainly are in fixed source form, where spaces aren't
> significant. Of course, one could make the rules different for fixed
> source form, but that's a complication.
>
> (Or one could just blow off fixed source form, which wouldn't bother me
> much, but then you've got a bigger debate with some people.)

If I had thought about it for more than 10 seconds before posting, it
would have occurred to me that you don't need a delimiter in fixed
source form at all because the label is already in dedicated columns.

But I just saw "blank delimiter", which set off my automatic alarm for
"problem in fixed source form" before I realized that labels are special
in terms of fixed-source parsing.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Gordon Sande

2005-05-26, 3:57 am

Gary L. Scott wrote:
> Richard E Maine wrote:
>
>
> I would have thought that starting with a colon would be better so that
> anything
> with a colon ending in space would be a label (no spaces in labels). I'm
> pretty sure I've seen that style of label before
>

The no space in labels seems a strange extra restriction on FIXED format
source.

>
> :label
>
> Are there parse issues with that?
>

In FIXED source format you would have

DO:SAMI=1,10

which is a DO by the comma at level 0 but is the label S and the
variable AMI or is the label SAM and the variable I?

The colon at the end matches the visual form of construct names and
avoids this token boundary issue for fixed form. In FREE format
they should be optional because they would be redundant so would
rarely be seen in practice

The real bother with having construct names also act a labels is the
tedium of describing the semantics of a labeled DO which can have
EXIT, CYCLE and GOTO using the same identifier for three distinct
purposes. Nothing would be new, it just would have to be rendered
into black and white in a consistent (and correct) form. ;-)

[color=darkred]
>
>

Gordon Sande

2005-05-26, 3:57 am

Richard E Maine wrote:
> In article <nospam-9C98FF.15442025052005@news.supernews.com>,
> Richard E Maine <nospam@see.signature> wrote:
>
>
>
>
> If I had thought about it for more than 10 seconds before posting, it
> would have occurred to me that you don't need a delimiter in fixed
> source form at all because the label is already in dedicated columns.

Except for the bothers with comments and continuation. My suggestion is
to leave the FIXED format label field for numbers as a least fuss
solution in the expectation that fixed format is a sleeping dog to left
alone. (Maybe it is dead but it is not worth telling the difference!)

> But I just saw "blank delimiter", which set off my automatic alarm for
> "problem in fixed source form" before I realized that labels are special
> in terms of fixed-source parsing.
>

Gary L. Scott

2005-05-26, 3:57 am

Gordon Sande wrote:
>
>
> Richard E Maine wrote:
>
>
>
> Except for the bothers with comments and continuation. My suggestion is
> to leave the FIXED format label field for numbers as a least fuss
> solution in the expectation that fixed format is a sleeping dog to left
> alone. (Maybe it is dead but it is not worth telling the difference!)
>

Yes, no more accommodation of fixed source form unless really trivial
and obvious (and someone actually wants it).
[color=darkred]
>

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

David Flower

2005-05-26, 8:57 am

Planned obsolescence for FORTRAN.

Much of my working life, maybe most, has been spent with existing code.
And it has all been fixed source!

One of the virtues of FORTRAN is that (with the single exception of F66
DO-loops) it is backwards compatible.

Walter Spector

2005-05-26, 3:59 pm

David Flower wrote:
> ...
> One of the virtues of FORTRAN is that (with the single exception of F66
> DO-loops) it is backwards compatible.

I presume you are referring to the 1-trip, 0-trip thing. Various F66 compilers
went either way, as the 0-trip requirement was not codified until Fortran-77.
If one restriced oneself to writing DO loops as the F66 Standard defined them,
they are still portable to this day.

OTOH, there are a number of other things which early Fortrans supported
and have gone by the wayside. Easy target is Hollerith constants - which
was eliminated from the F77 Standards. There also things like some forms
of I/O which appeared in pre-66 ANS Fortran (e.g., READ INPUT TAPE.)
Additions to the list of intrinsic functions. The various things that
F95 'depricated' (including fixed form source code), etc.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Richard E Maine

2005-05-26, 3:59 pm

In article <1117093664.960086.75770@f14g2000cwb.googlegroups.com>,
"David Flower" <DavJFlower@AOL.COM> wrote:

> One of the virtues of FORTRAN is that (with the single exception of F66
> DO-loops) it is backwards compatible.

Ahem. Single exception? Appendix A of the Fortran 77 standard lists 24
things that are not backward compatible in moving from f66 and f77.

I might add that the one-trip DO loop is *NOT* among the things listed.
That's because it was not standard-conforming f66, but was a property of
some (but not all) f66 implementations. If you want to talk about
compatibility with nonstandard coding practices, such as one-trip DO
loops,then there are many, many incompatibilities.

Among the f66 things that is not compatible with f77, there is the
extended range of a DO, but that's unlikely to be what you were talking
about.

I've figured out that I;m not interested in debating the merits of these
things with you. I'll just stick to the factual parts, such as the list
of 24 things in f77 Appendix A.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

mcalhoun@ksu.edu

2005-05-26, 3:59 pm

>> how is it possible to write:
[color=darkred]
>By using iostat= instead of err=.
>Whether that is preferable or not is another question. I have dropped
>err= (along with end=, and I prety much never used eor=) from my
>personal choice subset, but other people differ.

Although I type pretty well, I do still make typing mistakes, so years
ago I made "minimum number of lines of code" part of my programming
philosophy. Thus I PREFER

READ (5,*,ERR=999)

over

LOGICAL SomeVariable
...
READ (5,*,IOSTAT=SomeVariable)
IF (SomeVariable....) GO TO 999

because the first takes but one line while the latter takes two (or
three, if no other LOGICAL had already been defined).

For the same reason (and line count), I use alternate returns.
--
--Myron A. Calhoun.
Five boxes preserve our freedoms: soap, ballot, witness, jury, and cartridge
PhD EE (retired). "Barbershop" tenor. CDL(PTXS). W0PBV. (785) 539-4448
NRA Life Member and Certified Instructor (Home Firearm Safety, Rifle, Pistol)

John Harper

2005-05-26, 9:00 pm

In article <4295CC6A.5FA40C33@earthlink.net>,
Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
>David Flower wrote:
>
>OTOH, there are a number of other things which early Fortrans supported
>and have gone by the wayside. Easy target is Hollerith constants - which
>was eliminated from the F77 Standards.

True, but many f95 compiler-writers have kept them. With suitable
options the following will still compile, run, and write HELLO WORLD!

INTEGER J(3)
DATA J(1)/4HHELL/,J(2)/4HO WO/,J(3)/4HRLD!/
WRITE(6,666)J
666 FORMAT(3A)
END

(One f95 feature that reminds me of that sort of coding is that
boz-literal-constants may only appear in DATA statements. Even f2003
only allows them in a few more places: see constraint C410.)

John Harper, School of Mathematics, Statistics and Computer Science,
Victoria University, PO Box 600, Wellington, New Zealand
e-mail john.harper@vuw.ac.nz phone (+64)(4)463 5341 fax (+64)(4)463 5045

glen herrmannsfeldt

2005-05-26, 9:00 pm

John Harper wrote:

(snip)

> True, but many f95 compiler-writers have kept them. With suitable
> options the following will still compile, run, and write HELLO WORLD!
>
> INTEGER J(3)
> DATA J(1)/4HHELL/,J(2)/4HO WO/,J(3)/4HRLD!/
> WRITE(6,666)J
> 666 FORMAT(3A)
> END
>
> (One f95 feature that reminds me of that sort of coding is that
> boz-literal-constants may only appear in DATA statements. Even f2003
> only allows them in a few more places: see constraint C410.)

I would make the Format 3A4, but otherwise it looks fine.

The compilers I used would take apostrophed strings as an extension,
which I always thought looked better, too.

-- glen

Walter Spector

2005-05-27, 4:01 am

John Harper wrote:
>
> In article <4295CC6A.5FA40C33@earthlink.net>,
> Walter Spector <w6ws_xthisoutx@earthlink.net> wrote:
> ... Easy target is Hollerith constants - which
>
> True, but many f95 compiler-writers have kept them. With suitable
> options the following will still compile, run, and write HELLO WORLD!
>
> INTEGER J(3)
> DATA J(1)/4HHELL/,J(2)/4HO WO/,J(3)/4HRLD!/
> WRITE(6,666)J
> 666 FORMAT(3A)
> END

Now try doing similar, but with run-time formats. I wonder how many
current compilers allow numeric array names for formats? Using CDC
FTN 4 dialect of Fortran-66:

PROGRAM HELLO (OUTPUT, TAPE6=OUTPUT)
INTEGER J(2)
DATA J/10H(12H HELLO, 7H WORLD) /
WRITE (6,J)
END

Then there is the entertaining F66 feature of feeding a format spec similar to
the above into a READ statement, instead of a WRITE...

> (One f95 feature that reminds me of that sort of coding is that
> boz-literal-constants may only appear in DATA statements. Even f2003
> only allows them in a few more places: see constraint C410.)

Holleriths were, by the -66 Standard, allowed in 3 places: DATA statements,
FORMAT statements, and as actual args in CALL statements. They were also
typeless.

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

David Flower

2005-05-28, 8:57 am

Can anyone tell me why FORTRAN90 declared alternate returns, but not
ERR= descriptors, obsolescent ?

It seems to me wildly inconsistent.

Michael Metcalf

2005-05-28, 8:57 am

"David Flower" <DavJFlower@AOL.COM> wrote in message
news:1117267801.351319.213690@g44g2000cwa.googlegroups.com...
> Can anyone tell me why FORTRAN90 declared alternate returns, but not
> ERR= descriptors, obsolescent ?
>
> It seems to me wildly inconsistent.
>

Right. They both conflict with the rules of structured programming, but
that's the way the committee decided (and I don't ever remember a comparison
being made). Neither are in F.

Regards,

Mike Metcalf

James Giles

2005-05-28, 3:58 pm

David Flower wrote:
> Can anyone tell me why FORTRAN90 declared alternate returns, but not
> ERR= descriptors, obsolescent ?
>
> It seems to me wildly inconsistent.

Neither is likely to be deleted. And, until exception handling is
available, there is not really any suitable replacement for either.
The idea of decreasing legibility of code by liberally spreading
repeated tests of return-codes throughout procedures is not
very palatable.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Charles Russell

2005-05-28, 3:58 pm

Richard E Maine wrote:
[color=darkred]

The perspective differs according to whether you mostly write new code
or whether you mostly work with old code and want to avoid drastic
changes in style.

Gary L. Scott

2005-05-28, 8:57 pm

Charles Russell wrote:

> Richard E Maine wrote:
>
>
>
> The perspective differs according to whether you mostly write new code
> or whether you mostly work with old code and want to avoid drastic
> changes in style.

I would think that the majority of programmers would be writing new
code, else why call them programmers. Maintenance of old code is barely
"programming". Not belittling it, just that the language should be
evolving "forward". It should be incorporating "new knowledge" learned
through implementation of other languages. Not willy-nilly, but in a
deliberate, learned, logical, studied way.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Charles Russell

2005-05-29, 3:57 pm

Gary L. Scott wrote:

> I would think that the majority of programmers would be writing new
> code, else why call them programmers.

A time was, when most people who wrote fortran were called "users."

Gary L. Scott

2005-05-29, 3:57 pm

Charles Russell wrote:

> Gary L. Scott wrote:
>
>
>
> A time was, when most people who wrote fortran were called "users."

I am one of those...but that is ancient history.

--

Gary Scott
mailto:garyscott@ev1.net

Fortran Library: http://www.fortranlib.com

Support the Original G95 Project: http://www.g95.org
-OR-
Support the GNU GFortran Project: http://gcc.gnu.org/fortran/index.html

Why are there two? God only knows.

If you want to do the impossible, don't hire an expert because he knows
it can't be done.

-- Henry Ford

Rich Townsend

2005-05-30, 3:58 am

Gary L. Scott wrote:
> Charles Russell wrote:
>
>
>
>
> I am one of those...but that is ancient history.
>

But, at least in academia, I think there still persists the overlap
between "user" and "programmer" that -- historically -- has made Fortran
so popular. In my own case, almost all of the programs I write are for
my own use, as well as use by colleagues and collaborators.

This, of course, is the two-edged sword that is Fortran. You don't have
to read Knuth to program in Fortran, and that's a good thing. But most
people haven't read Knuth when they program in Fortran, and that's a bad
thing.

cheers,

Rich

Boo, hoo!

2005-05-30, 3:58 am

"Rich Townsend" <rhdt@barVOIDtol.udel.edu> wrote in message
news:d7dr3s$6kr$1@scrotar.nss.udel.edu...

>In my own case, almost all of the programs I write are for
> my own use, as well as use by colleagues and collaborators.
>

Ah Shithead, oops, I meant Dickhead!

What a relief, you write programs for nobodies who do no harm and even less
good. Bravo!

> This, of course, is the two-edged sword that is Fortran. You don't have
> to read Knuth to program in Fortran, and that's a good thing. But most
> people haven't read Knuth when they program in Fortran, and that's a bad
> thing.

Baloney, those who program in Fortran can't, Knuth couldn't give a toss and
neither does anyone else other than regular Fortran sewing club members.
Fortran devotees are as pathetic and bankrupt as the creatures in Scott's
'Staying On', but far less interesting, they lacking an iota of insight
into their essential obsolescence, hence the current CLF prattle on f2008,
f2003 having been abandoned due to, what's that word?, disinterest, that's
the one.
--
You're Welcome,
Gerry T.
______
"Nobody can get the truth out of me because even I don't know what it is. I
keep myself in a constant state of utter confusion." -- Col Sam Flagg,
ICORPS dropin to the 4077th M*A*S*H

Dave Thompson

2005-05-31, 4:00 am

On Fri, 20 May 2005 16:23:27 -0700, glen herrmannsfeldt
<gah@ugcs.caltech.edu> wrote:

> Richard E Maine wrote:
<snip>
>
> C and PL/I have more descriptive alphanumeric labels, which helps some.
> As I understand it PASCAL has numeric labels specifically to discourage
> their use.
>
Ada as usual tries for the best of both worlds; it has alphanumeric
labels for goto -- and an ugly syntax to discourage their use. <G>
(And Pascal is a 'proper' name = of a person, the French mathematician
scientist and Christian Blaise Pascal, and was therefore not-caps even
before the new rules for acronyms.)

- David.Thompson1 at worldnet.att.net

NuclearWizard

2005-05-31, 4:01 pm

I use GOTO 666 for errors.

Sponsored Links