Declaring arrays in subs.
Emilio C. Lopes
Hi all,
I have the following subroutine (just the header):
SUBROUTINE MYSUB (X, N)
In this subroutine, X is suposed to be an *array* of dimension
up to N. Obviously, it must be declared as such in the unit that
call this sub. So, what is the better way of declaring X in MYSUB?
I see two possibilities:
1-
SUBROUTINE MYSUB (X, N)
DIMENSION X(N)
2-
SUBROUTINE MYSUB (X, N)
DIMENSION X(*)
I know that both work, but which one is more robust?
Using f77.
Regards, Emilio.
--
Emilio C. Lopes E-mail: e...@gluon.if.usp.br
Instituto de Fisica e...@if.usp.br or e...@uspif.if.usp.br
Universidade de Sao Paulo ecl%us...@brfapesp.bitnet
Caixa Postal 66318 uspif::ecl
05389-970 Sao Paulo - SP Phone: (55)(11) 818-6724 (Voice)
BRAZIL (55)(11) 814-0503 (Fax)
Steve Lionel
In article <3p8igt$h...@bee.uspnet.usp.br>, e...@meson.if.usp.br
|>1-
|> SUBROUTINE MYSUB (X, N)
|> DIMENSION X(N)
|>
|>2-
|> SUBROUTINE MYSUB (X, N)
|> DIMENSION X(*)
|>
|>I know that both work, but which one is more robust?
The first is preferable for several reasons:
1) It allows the compiler to know how the dimension of X relates
to N (especially if you use N as the bound of a DO loop) allowing
for better optimization.
2) It allows the compiler to detect when you have accidentally
accessed beyond the bounds of the array.
3) It allows you to use array X without subscripts in I/O statements.
4) The use of assumed-size arrays (the (*) bounds) is being proposed
as an "obsolescent feature" in Fortran 95.
--
Steve Lionel Mail: lio...@quark.enet.dec.com
DEC Fortran Development WWW: http://www.digital.com/info/slionel.html
Digital Equipment Corporation CompuServe: 75263,3001
110 Spit Brook Road, ZKO2-3/N30
Nashua, NH 03062-2698 "Free advice is worth every cent"
For a summary of Digital's Internet services, send mail to in...@digital.com
Robert Corbett
Steve Lionel <lio...@quark.enet.dec.com> wrote:
>
> 4) The use of assumed-size arrays (the (*) bounds) is being proposed
> as an "obsolescent feature" in Fortran 95.
Of course, many programmers have yet to start using assumed-size arrays.
A lot of programs and programmers use `1' instead of `*' to indicate an
assumed-size array.
Sincerely,
Bob Corbett
Rick Venable
> Steve Lionel <lio...@quark.enet.dec.com> wrote:
> > 4) The use of assumed-size arrays (the (*) bounds) is being proposed
> > as an "obsolescent feature" in Fortran 95.
On 17 May 1995 06:41:44 GMT Robert Corbett pontificated:
> Of course, many programmers have yet to start using assumed-size arrays.
> A lot of programs and programmers use `1' instead of `*' to indicate an
> assumed-size array.
You mean like some of the routines published in Numerical Recipes? Okay,
it was the first edition, but still...
--
Rick Venable =====\ |=| "Eschew Obfuscation"
FDA/CBER Biophysics Lab |____/ |=|
Bethesda, MD U.S.A. | \ / |=| / Not an official statement \
rven...@deimos.cber.nih.gov \/ |=| \ or position of the FDA. /
Phillip Helbig
>> In article <3pajvr$q...@jac.zko.dec.com>,
>> Steve Lionel <lio...@quark.enet.dec.com> wrote:
>> > 4) The use of assumed-size arrays (the (*) bounds) is being proposed
>> > as an "obsolescent feature" in Fortran 95.
As far as Fortran(90) goes, I'm pretty much up-to-date (should be because I
program in it :); could someone publish the lists of obsolete and deleted
features in F95? In this particular case, I assume that there is a more
elegant way, but does (*) really need to be declared obsolete?
Steve Lionel
In article <3pp923$4...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig
|>As far as Fortran(90) goes, I'm pretty much up-to-date (should be because I
|>program in it :); could someone publish the lists of obsolete and deleted
|>features in F95? In this particular case, I assume that there is a more
|>elegant way, but does (*) really need to be declared obsolete?
Obsolete means that there is a more modern syntax in the language which should
be used instead. I sort-of agree that most uses of assumed-size arrays
should be replaced with those where the bounds are more explicit (or are
passed implicitly).
Here's the *PROPOSED* (that is, in the current draft) list of obsolescent
and deleted features in F95. The draft has not gone to public comment yet,
so anything may change.
Obsolescent:
Arithmetic IF
Shared DO termination and termination on other than END DO
or CONTINUE
Alternate return
Computed GOTO
Statement functions
DATA statements among executable statements
Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
Fixed form source (!)
Assumed size arrays
CHARACTER* form of CHARACTER declaration (use (LEN=) instead)
Deleted (programs using these features are not conformant to F95)
Real and double precision DO variables
Branch to an ENDIF from outside its IF construct
PAUSE statement
ASSIGN and assigned GOTO and assigned format specifier
H edit descriptor
F95-conformant processors are required to have the ability to flag use of
obsolescent features. There is no requirement that deleted features actually
be removed from the compiler. Digital will *NOT* remove deleted features from
its compilers - we see no point to deleting features from the standard (but
this has been argued in the group before, no real sense in doing it again.)
My understanding is that most other vendors share this position (but I don't
speak for them.)
Andreas Bacher
[Stuff deleted]
>
> > Statement functions
>
> Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
> What, however, is the REASON why statement functions are to be branded
> obsolete? I kind of like them myself, and wouldn't like to see them go
> without a real reason.
Seconded.
[Stuff deleted]
>
> > Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
>
> this might be easier in Fortran90, why the extra work? This doesn't look
> like bad practice, so WHY should this go?
>
> > Fixed form source (!)
>
> Make that a few more exclamation marks. Someone pointed out that one
> can make free-form source look ALMOST like fixed-form, but this isn't
> really the point. Again, WHY should this be declared obsolescent? What
> I like about FORTRAN is that one can make it really READABLE if wanted.
Seconded.
To reinforce,
i) contrary to common views I've found the labelling combined with the fixed
form to even add readability, iff one adopts some additional conventions,
like hierarchical naming in DO nests (e.g. 2011>3011,3012>4011, 2021 ...),
and placing unavoidable GOTOs, ERRs, and such flush right.
ii)Some F77 code may have been laid out including non-standard pre-processing
controls in columns 73 thru 80, e.g. an Ocean General Circulation Model
of size some 50,000 lines which I work with but have not written myself.
[Stuff deleted]
> Here's my list of which, whether needed in FORTRAN77 or not, are not really
> needed in Fortran90, and, although (as, however, is true with almost
> everything) many have been used ubiquitously (by myself as well), which
> basically through continued use crowd out the better way of doing it and which
> I would like to see declared obsolete in F200(?)
If these suggestions apply before the year 2100 too, then I would hate to see
these fade away:
>
> COMMON, EQUIVALENCE, ENTRY, STOP
>
The first two, especially their combination, are very old fashioned but still
quite useful for important special cases, and I would not like being forced
to go to extra migrating lengths. I use this, typically, to multiply n arrays,
all requiring static storage to start with, by a constant, EQUIVALENCEing a
large 1dim array to the first storage element of the first of these arrs.
which are lined up in COMMON. The operation then uses a favorable (big) vector
length. Not saying there would be no alternatives, I've liked it, not least
its portability.
[Stuff deleted]
Andreas Bacher
Max-Planck-Institut fuer Meteorologie
Bundesstr. 55
20146 Hamburg
Germany
E-mail: bac...@dkrz.d400.de
Phillip Helbig
>Here's the *PROPOSED* (that is, in the current draft) list of obsolescent
>and deleted features in F95. The draft has not gone to public comment yet,
>so anything may change.
I guess that this is the best place for some fruitful discussion on this
topic; it seems that there is still time to make some changes. I would
appreciate as much feedback as possible. If the bandwidth looks too large,
or the subject matter is a bit off the mark, feel free to send me email.
Be just as verbose whether you agree or disagree with my comments!
I don't want to start up the debate about what it PRACTICALLY means when
something is declared obsolete or is deleted. I'm sure there are many others
who stick to the standard as closely as possible for a variety of reasons, even
if (like me) the last thing they would think of would be changing vendors.
Code might be used by other people, and who REALLY knows what the world
will look like 40 years in the future.
>Obsolescent:
> Arithmetic IF
> Shared DO termination and termination on other than END DO
> or CONTINUE
> Alternate return
> Computed GOTO
I've never used any of these even in FORTRAN77. Basically, all these things
make for unstructured programming, so I don't mind seeing them declared
obsolescent (or even deleted).
> Statement functions
Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
What, however, is the REASON why statement functions are to be branded
obsolete? I kind of like them myself, and wouldn't like to see them go
without a real reason.
> DATA statements among executable statements
Bad practice, should be discouraged.
> Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
Now I always liked not computing the length in the calling routine. Although
this might be easier in Fortran90, why the extra work? This doesn't look
like bad practice, so WHY should this go?
> Fixed form source (!)
Make that a few more exclamation marks. Someone pointed out that one
can make free-form source look ALMOST like fixed-form, but this isn't
really the point. Again, WHY should this be declared obsolescent? What
I like about FORTRAN is that one can make it really READABLE if wanted.
Free-form source can be made readable, too, but a compiler that notices
whether or not you start in column 7 is picky enough to enforce a clean
style. It's like the legend(?) of screw slots lining up on Porsches. Of
course, it doesn't matter as far as performance goes, but anyone being this
picky here is probably being picky where it counts, too. I think we need
some real debate on this point.
> Assumed size arrays
Same remarks as for CHARACTER*(*).
> CHARACTER* form of CHARACTER declaration (use (LEN=) instead)
OK, I'll be consistent and adopt the new F90 style.
>Deleted (programs using these features are not conformant to F95)
> Real and double precision DO variables
> Branch to an ENDIF from outside its IF construct
> PAUSE statement
> ASSIGN and assigned GOTO and assigned format specifier
> H edit descriptor
Again, stuff I've never used and which is certainly the source of many
errors. (The only exception being PAUSE, which I think is useful for
testing purposes. However, this can be handled in other ways. The original
motivation for PAUSE is gone, but some still use it, so again WHY should
it go.)
Here's my list of which, whether needed in FORTRAN77 or not, are not really
needed in Fortran90, and, although (as, however, is true with almost
everything) many have been used ubiquitously (by myself as well), which
basically through continued use crowd out the better way of doing it and which
I would like to see declared obsolete in F200(?). Deleting them would, of
course, break too much existing code, and, which is not the case with some
very bad features, their existence in old code isn't that hard to maintain.
Again, I would appreciate much feedback.
COMMON, EQUIVALENCE, ENTRY, STOP
>F95-conformant processors are required to have the ability to flag use of
>obsolescent features. There is no requirement that deleted features actually
>be removed from the compiler. Digital will *NOT* remove deleted features from
>its compilers - we see no point to deleting features from the standard (but
>this has been argued in the group before, no real sense in doing it again.)
>My understanding is that most other vendors share this position (but I don't
>speak for them.)
>--
>Steve Lionel Mail: lio...@quark.enet.dec.com
>DEC Fortran Development WWW: http://www.digital.com/info/slionel.html
>Digital Equipment Corporation CompuServe: 75263,3001
>110 Spit Brook Road, ZKO2-3/N30
>Nashua, NH 03062-2698 "Free advice is worth every cent"
>For a summary of Digital's Internet services, send mail to in...@digital.com
Phillip
Phillip Helbig Tel. .............. +49 40 7252 4110
Hamburger Sternwarte Email .... phe...@hs.uni-hamburg.de
Gojenbergsweg 112 Fax ............... +49 40 7252 4198
D-21029 Hamburg Telex ............... 217884 hamst d
Steve Lionel
In article <3prr2k$8...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig
<phe...@hs.uni-hamburg.de> writes:
|>Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
|>What, however, is the REASON why statement functions are to be branded
|>obsolete? I kind of like them myself, and wouldn't like to see them go
|>without a real reason.
The draft says:
Statement functions are subject to a number of non-intuitive
restrictions and are a potential source of error since their
syntax is easily confused with that of an assignment statement.
|>> Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
|>
|>Now I always liked not computing the length in the calling routine. Although
|>this might be easier in Fortran90, why the extra work? This doesn't look
|>like bad practice, so WHY should this go?
Assumed length for functions is an irregularity in the language
since elsewhere in Fortran the philosophy is that the attributes
of a function result depend only on the actual arguments of the
invocation and on any data accessible by the function through
use or host association. This facility may be replaced by the
use of a subroutine whose arguments correspond to the function
result and the function arguments.
|>
|>> Fixed form source (!)
|>
|>Make that a few more exclamation marks. Someone pointed out that one
|>can make free-form source look ALMOST like fixed-form, but this isn't
|>really the point. Again, WHY should this be declared obsolescent?
Fixed form source was designed when the principal machine readable
input medium was punched cards. Now that new and amended programs
are generally entered via keyboards with screen displays, it is an
unnecessary overhead, and is potentially error-prone, to have to
locate columns 6, 7 or 72 on a line. Free form source was designed
especially for the more modern technology.
It is a simple matter for a software tool to convert from fixed to
free source form.
|>Here's my list of which, whether needed in FORTRAN77 or not, are not really
|>needed in Fortran90, and, although (as, however, is true with almost
|>everything) many have been used ubiquitously (by myself as well), which
|>basically through continued use crowd out the better way of doing it and which
|>I would like to see declared obsolete in F200(?). Deleting them would, of
|>course, break too much existing code, and, which is not the case with some
|>very bad features, their existence in old code isn't that hard to maintain.
|>Again, I would appreciate much feedback.
|>
|>COMMON, EQUIVALENCE, ENTRY, STOP
You have a lot of company, at least for the first three. But COMMON and
EQUIVALENCE, at least, were the subject of bitter debate as to whether or not
they should go on the obsolete list, so I am told.
Jeff Templon
: Here's my list of which, whether needed in FORTRAN77 or not, are not really
: needed in Fortran90, and, although (as, however, is true with almost
: everything) many have been used ubiquitously (by myself as well), which
: Again, I would appreciate much feedback.
: COMMON, EQUIVALENCE, ENTRY, STOP
Here is your feedback. I have to say that in almost every document
I've seen about Fortran 90, the COMMON and EQUIVALENCE statements
have been labelled as "very dangerous to use", and I am told that
there are completely equivalent and much safer methods provided by
Fortran 90 to accomplish the same purpose.
This, my friends, is bullcrap. I can only assume that the people
who are preaching this poppycock have no occasion to actually do
anything with the computer hardware. If we leave hardware out of
the picture, I agree completely.
Our application (Nuclear Physics) requires having the computer
accept and process large amounts of data coming in at high speeds.
So much data, and so high speeds, that every second counts (we're
busy right now trying to figure out how to get an 8mm tape farm to
write fast enough to accept all the data.) The data, once accepted
by the computer, needs to be processed very quickly, some summary
information on each chunk of data stored away in memory (sometimes
global, shared memory, so that another data-presenter program can
look at some subset of the results as it comes in, for validation
purposes), and then on to the next chunk.
We typically try to have the drivers that are accepting the data
write it in some contiguous chunk of memory and send and address to
the 'analyzer' program. We have an unpacker routine which may take
selected parts of the data and store them in other memory
locations. We put a high premium on having the data contiguously
stored in memory, since sometimes you may want to acess the same
data in several different ways (depending on what you want to do
with it); our code is sprinkled liberally with COMMON, EQUIVALENCE,
UNION, MAP, STRUCTURE.
If we were to write it differently (not using storage association),
the code would most likely slow down by at least a factor of three
(this is what I remember hearing from someone who posted about the
difference of using compile-time allocated arrays vs. run-time
allocation for some matrix algebra program.) Maybe even more.
Furthermore it would become more complicated; the fact that you
can't build in the different methods of access, directly into the
derived type (as you can with STRUCTURE, UNION and MAP) means that
you have to have a separate pointer declaration for each instance
of the derived type, instead of having the compiler handle it for
you.
Fine, if you don't use the hardware, stay away from storage
association. But just because you don't use it, don't hog-tie
those of us who do. You'll just force us to write lots and lots of
code which relies on all those DEC extensions you're trying to
purge out of the language. I guess DEC understands that sometimes
people actually want to do something with the hardware, and need
high performance.
Dr. Jeff Templon
MIT Lab for Nuclear Science
WIlliam B. Clodius
> <snip>
>
> I guess that this is the best place for some fruitful discussion on this
> topic; it seems that there is still time to make some changes. I would
> appreciate as much feedback as possible. <snip>
>
> > Statement functions
>
> Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
> What, however, is the REASON why statement functions are to be branded
> obsolete? I kind of like them myself, and wouldn't like to see them go
> without a real reason.
Internal subprograms provide more functionality and clarity, albeit at
the cost of some wordiness. Most language designers, as opposed to
most compiler implementors and many language users, dislike duplication
of functionality. The lack of duplication of features does make it
simpler to explain code to those with minimal familiarity with the
language, i.e., management. The justification of the deletion I
remember as suggesting that the syntax of statement functions is confusing
but I have never had trouble with it.
><snip>
> > Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
>
> Now I always liked not computing the length in the calling routine. Although
> this might be easier in Fortran90, why the extra work? This doesn't look
> like bad practice, so WHY should this go?
You can use inferred shape, etc.. Most language designers dislike duplication,
hence the deletion.
> > Fixed form source (!)
>
> Make that a few more exclamation marks. Someone pointed out that one
> can make free-form source look ALMOST like fixed-form, but this isn't
> really the point. Again, WHY should this be declared obsolescent? What
> I like about FORTRAN is that one can make it really READABLE if wanted.
> Free-form source can be made readable, too, but a compiler that notices
> whether or not you start in column 7 is picky enough to enforce a clean
> style. <snip>
Fixed source form, combined with other features of Fortran, is error prone.
In particular the acceptance of spaces in variable names, the 72 column
limit, the meaning of tabs, numeric labels, continuation lines, and a few
other aspects. Clean style involves more than starting in column 7 or
keeping the lines short, and most compilers in effect only enforce those
two rules. The few empirical studies, as opposed to a programmer's gut
feelings indicate that the free source form is better. Fixed source form is
also the only obsolescent or deleted feature for which a free automatic
means of translation exists.
><snip>
> Here's my list of which, whether needed in FORTRAN77 or not, are not really
> needed in Fortran90, and, although (as, however, is true with almost
> everything) many have been used ubiquitously (by myself as well), which
> basically through continued use crowd out the better way of doing it and which
> I would like to see declared obsolete in F200(?). Deleting them would, of
> course, break too much existing code, and, which is not the case with some
> very bad features, their existence in old code isn't that hard to maintain.
> Again, I would appreciate much feedback.
>
> COMMON, EQUIVALENCE, ENTRY, STOP
> <snip>
With the possible exception of STOP, most F90 texts, including those
written by members of X3J3, would agree with you that these features
are technically obsolescent. However these features are considerably
more difficult to remove from old code and ubiquitous in old code.
I cannot see X3J3 making COMMON or EQUIVALENCE obsolescent in F2000,
ENTRY perhaps. Simillarly implicit typing is deprecated in most texts
but unlikely to be eliminated.
Tero . Tommila
>> Statement functions
>Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
>What, however, is the REASON why statement functions are to be branded
>obsolete? I kind of like them myself, and wouldn't like to see them go
>without a real reason.
Why do you need any statement functions when you always can write a "real"
function (subroutine) ?
I don't see any need for statement functions and have never used any...
>> Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
>Now I always liked not computing the length in the calling routine. Although
>this might be easier in Fortran90, why the extra work? This doesn't look
>like bad practice, so WHY should this go?
Here I agree ! It has been very handy to just declare character*(*) and
let the compiler do the rest.
>> Fixed form source (!)
This may well go as you can always write in any style in free format.
You may code in "fixed" form if you want but the compiler doesn't enforce
you to any particular coding format. Saves some time when you don't
need to be aware of columns 6 and 7 etc.
>> Assumed size arrays
>Same remarks as for CHARACTER*(*).
Agreed. Of course you could always use dimension (1) in subroutine and
reference the array through variables (but then you can't write the whole
array without implicit loops ?).
>> CHARACTER* form of CHARACTER declaration (use (LEN=) instead)
>OK, I'll be consistent and adopt the new F90 style.
When do we get dynamic characters, i.e. a simple character declaration
without any info about length ?
>COMMON, EQUIVALENCE
Common has been good in subroutine libraries where you need to transfer
some "internal" data between subroutines not callable by the user...
Equivalence is good at blanking large character arrays...
--
Sepe Susi ("Zeke the Wolf")
alias Tero Tommila
KCL/Finland
se...@rankki.kcl.fi
Phillip Helbig
>I guess that this is the best place for some fruitful discussion on this
>topic; it seems that there is still time to make some changes. I would
>appreciate as much feedback as possible. If the bandwidth looks too large,
>or the subject matter is a bit off the mark, feel free to send me email.
>Be just as verbose whether you agree or disagree with my comments!
Just adding a few comments, based on email responses and postings, to clarify
some points and keep the discussion fruitful.
>>Obsolescent:
>> Arithmetic IF
>> Shared DO termination and termination on other than END DO
>> or CONTINUE
>> Alternate return
>> Computed GOTO
Seems to be NO reason for keeping these around.
>> Statement functions
>Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
>What, however, is the REASON why statement functions are to be branded
>obsolete? I kind of like them myself, and wouldn't like to see them go
>without a real reason.
Should have said internal routines there (CONTAINS). Many others seem
to like them, but it's been pointed out that the syntax can be confusing
and deviates from the `Fortran feel' in some sense. The main reason I
liked them was the PRIVATE aspect in Fortran77; this exists in F90 as
well, and there are many more possibilities as far as modularisation
goes. So, we would lose nothing by getting rid of them, and gain the
advantage of a more transparent code.
>> DATA statements among executable statements
Goodbye.
>> Assumed-length character functions (CHARACTER*(*) FUNCTION FOO)
>Now I always liked not computing the length in the calling routine. Although
>this might be easier in Fortran90, why the extra work? This doesn't look
>like bad practice, so WHY should this go?
>> Assumed size arrays
>Same remarks as for CHARACTER*(*).
Here, several have pointed out that the user comfort stands in no sensible
relation to the compiler overhead needed to support such stuff, and that
some strange `undocumented features' exist in this area. One can, and
should, avoid these in Fortran90.
>> Fixed form source (!)
>Make that a few more exclamation marks. Someone pointed out that one
>can make free-form source look ALMOST like fixed-form, but this isn't
>really the point. Again, WHY should this be declared obsolescent? What
>I like about FORTRAN is that one can make it really READABLE if wanted.
>Free-form source can be made readable, too, but a compiler that notices
>whether or not you start in column 7 is picky enough to enforce a clean
>style. It's like the legend(?) of screw slots lining up on Porsches. Of
>course, it doesn't matter as far as performance goes, but anyone being this
>picky here is probably being picky where it counts, too. I think we need
>some real debate on this point.
It seems the main reason to get rid of fixed-form source is to get rid of
non-significant blanks, which makes the code harder to swallow for the
compiler, is a source of unwanted errors and makes for an overblown syntax
in declarations in order for the declaration to be uniquely interpreted by
the compiler. Here, I agree. Perhaps one should have eliminated just the
nonsignificant blanks, and kept the form otherwise the same. Eliminating
nonsignificant blanks from legacy code is probably possible. But it seems
that other features cause problems, which might not be mitigated by the
advantages:
! comments --- fine to introduce a new symbol (also for inline comments)
but the fact that C and * are no longer recognised means
one has to rewrite old code. Now an entire routine in
fixed form is OK, I'm talking about reusing chunks of code.
stuff after column
72 significant --- perhaps this could be a problem, since many
programmes have stuff there the compiler should
ignore. Probably one wouldn't reuse chunks of
such code, but imagine that such code wouldn't
be recognised as standard. Not a personal concern
of mine, but something to think about.
& at end of line --- it would be more practical to have the SIGNIFICANT
continuation symbol at the BEGINNING of the line.
This is what I was talking about when I mentioned
the legibility of fixed form. I agree that the
space business can cause problems, but couldn't one
have made spaces significant and put the SIGNIFICANT
continuation mark at the beginning of the line?
>> CHARACTER* form of CHARACTER declaration (use (LEN=) instead)
>OK, I'll be consistent and adopt the new F90 style.
>>Deleted (programs using these features are not conformant to F95)
>> Real and double precision DO variables
>> Branch to an ENDIF from outside its IF construct
>> PAUSE statement
>> ASSIGN and assigned GOTO and assigned format specifier
>> H edit descriptor
>Again, stuff I've never used and which is certainly the source of many
>errors. (The only exception being PAUSE, which I think is useful for
>testing purposes. However, this can be handled in other ways. The original
>motivation for PAUSE is gone, but some still use it, so again WHY should
>it go.)
PAUSE seems to be bad because the behaviour is ill-defined. OK, it can go.
>Here's my list of which, whether needed in FORTRAN77 or not, are not really
>needed in Fortran90, and, although (as, however, is true with almost
>everything) many have been used ubiquitously (by myself as well), which
>basically through continued use crowd out the better way of doing it and which
>I would like to see declared obsolete in F200(?). Deleting them would, of
>course, break too much existing code, and, which is not the case with some
>very bad features, their existence in old code isn't that hard to maintain.
>Again, I would appreciate much feedback.
>COMMON, EQUIVALENCE, ENTRY, STOP
It looks like the common uses of EQUIVALENCE can be better implemented
with RESHAPE. (And no one needs it to save on RAM anymore, which I
believe was was the original motivation.) As with EQUIVALENCE, with
COMMON there is a lot of opposition to it going. Use a module is the
reply, and this solves many problems, but what about the transparency?
If I have my global variables in COMMON blocks, instead of in a module,
then they are declared in every routine which uses them (of course I
declare everything explicitly). This makes changes more difficult, since
they have to be made everywhere. There's also the question of conflicting
COMMON block names when using routines written by someone else. The module
concept gets rid of these problems. However, when MAINTAINING code, it
is useful to have all types, dimensions and so on declared in the
routine, and is this loss of transparency offset by the lack of a need to
work around the other two problems? The advantage with COMMON is that one
can examine the declarations in the same routine when working out what's
happening and how to change/improve it.
Some people have pointed out that STOP, while it might be superfluous
just before END, might be needed to STOP the programme when an error
occurs several levels down. This seems to make sense, but in the same
spirit, one should not despise RETURN, since a RETURN, while not needed
just before the END of a SUBROUTINE, might be needed in the middle as an
abnormal exit. The alternative is GOTO (!) or checking flags at the entrance
to each block, which hardly makes for legible or maintainable code. Many
think RETURN should go, but it seems that one must keep both (for similar
reasons) or there must be an elegant solution to this problem, which I
am perhaps missing.
Steve Lionel
In article <3pt5i3$h...@senator-bedfellow.MIT.EDU>, tem...@studbolt.mit.edu
(Jeff Templon) writes:
|>Phillip Helbig (phe...@hs.uni-hamburg.de) wrote:
|>
|>: Here's my list of which, whether needed in FORTRAN77 or not, are not really
|>: needed in Fortran90,
|>
|>: COMMON, EQUIVALENCE, ENTRY, STOP
|>
|>Fine, if you don't use the hardware, stay away from storage
|>association. But just because you don't use it, don't hog-tie
|>those of us who do. You'll just force us to write lots and lots of
|>code which relies on all those DEC extensions you're trying to
|>purge out of the language. I guess DEC understands that sometimes
|>people actually want to do something with the hardware, and need
|>high performance.
Not that I disagree with your basic position that you need features that
give you access to the best performance, but I feel I must point out that
none of the features Phillip has listed as "not needed" are DEC extensions.
In the text of your posting you mentioned STRUCTURE/RECORD - F90 has
derived types which, for the most part, can be used to replace
STRUCTURE/RECORD, but I have never seen ANYONE suggest that STRUCTURE/RECORD
was poor programming practice.
You may use EQUIVALENCE a lot because you're not using STRUCTURE/RECORD to
its full capability. COMMON is useful to you because most vendors have
made it possible to locate COMMON variables in shared memory - as a
data abstraction method itself, F90's MODULEs (with variables declared
within) are a better method and no less efficient, but you will probably
have to continue to use COMMON for shared memory extensions.
Nunan
Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>
>It looks like the common uses of EQUIVALENCE can be better implemented
>with RESHAPE. (And no one needs it to save on RAM anymore, which I
>believe was was the original motivation.)
Excuse me?! Nobody runs problems which are limited by the amount of RAM
on their computers?! I beg to differ.
>Some people have pointed out that STOP, while it might be superfluous
>just before END, might be needed to STOP the programme when an error
>occurs several levels down. This seems to make sense, but in the same
>spirit, one should not despise RETURN, since a RETURN, while not needed
>just before the END of a SUBROUTINE, might be needed in the middle as an
>abnormal exit. The alternative is GOTO (!) or checking flags at the entrance
>to each block, which hardly makes for legible or maintainable code.
I agree. RETURN and STOP are similar to EXIT, but refer to larger
program units, rather than just loops. I hope EXIT is not on the
chopping block already. :) I suppose one could replace STOP with
EXIT PROGRAM, and replace RETURN with EXIT FUNCTION or EXIT SUBROUTINE,
but why not leave well enough alone?
Bill (nu...@physics.ucla.edu)
Glen Reesor
> In <3prr2k$8...@rzsun02.rrz.uni-hamburg.de> Phillip Helbig <phe...@hs.uni-hamburg.de> writes: Yes, that was I!
>
> >I guess that this is the best place for some fruitful discussion on this
> >topic; it seems that there is still time to make some changes. I would
> >appreciate as much feedback as possible. If the bandwidth looks too large,
> >or the subject matter is a bit off the mark, feel free to send me email.
> >Be just as verbose whether you agree or disagree with my comments!
>
> Just adding a few comments, based on email responses and postings, to clarify
> some points and keep the discussion fruitful.
>
>
> >>Obsolescent:
>
[snip]
> >> Real and double precision DO variables
Could someone point out the reason for this being Bad?
--
Glen Reesor Opinions are mine, only mine, and definitely
<ree...@crl.aecl.ca> not my employer's.
Dan Pop
>> >> Real and double precision DO variables
>
>Could someone point out the reason for this being Bad?
DO 10 X = 0.0, 1.0, 0.1
How many times is this loop executed on a system using binary floating
point (as most of todays systems do)?
Dan
--
Dan Pop
CERN, CN Division
Email: dan...@afsmail.cern.ch
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Craig Dedo
>In article <3puji0$k...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>> In <3prr2k$8...@rzsun02.rrz.uni-hamburg.de> Phillip Helbig <phe...@hs.uni-hamburg.de> writes: Yes, that was I!
>>
>> >> Real and double precision DO variables
>Could someone point out the reason for this being Bad?
>--
>Glen Reesor Opinions are mine, only mine, and definitely
><ree...@crl.aecl.ca> not my employer's.
Dear Glen,
**************************
Disclaimer: Any ideas or opinions are strictly mine and do NOT reflect
an opinion or official position of X3J3, ANSI, WG5, ISO, or any other
standards organization.
**************************
I am a member of X3J3 and tried to prevent the removal of this feature.
Unfortunately, I was substantially in the minority.
While I can speak only from my own observations and cannot speak for
other members, it is my belief that most members believed that REAL and
DOUBLE PRECISION DO loop index variables are a dangerous and error prone
feature. Following are some of the reason that they gave me during debate
and informal conversations for removal of this feature.
1. Most Fortran programmers are not very well educated on the dangers
and behaviors of REAL type variables and the consequences of round off
errors.
2. Because of this, in many cases where the loop control variable is
REAL or DOUBLE PRECISION, the loop may easily execute one less or one more
time than the programmer intended. In cases where the intended loop count
is in the thousands or higher, this loop count error may differ from the
intended loop count by more than one.
3. Due to roundoff error, the value of the loop index may drift far
from the intended value on any given iteration. This effect is cumulative.
In extreme cases, the loop control variable may never reach its final value.
This is because the increment amount is less than the difference between
successive numbers in the least significant digit. For example, if the
increment is 1.0, the final value is 1.0e+09 (i.e. 1 billion), and the
programmer is (foolishly) using a REAL type which has only 6 decimal digits
of precision, the loop will never reach its intended final value.
Result: an infinite loop.
4. Some programmers tried using REAL loop indexes to access array
elements, an application for which REAL indexes are wholly inappropriate.
Due to roundoff errors, this practice can easily access the wrong data.
I tried arguing that these problems arise more from programmer ignorance
than any real danger on the part of the feature. These problems can be
avoided through proper programmer education on the nature of REAL data
objects inside of the computer.
I also tried to argue that this feature offers real value and
functionality and does NOT duplicate other features. Using a REAL valued DO
loop index variable is more intuitive and straightforward in certain
situations than using an INTEGER, converting it to REAL, and then using the
result. I believe that as designers of Fortran, X3J3 should be encouraging
intuitive and straightforward programming style.
Unfortunately, the majority did not agree with my point of view.
Sincerely,
--
Craig T. Dedo Internet: Craig...@mixcom.com
Elmbrook Computer Services Voice Phone: (414) 783-5869
17130 W. Burleigh Place
Brookfield, WI 53005 Disclaimer: These opinions are mine alone.
USA They do NOT represent any organization.
"Those who would give up essential Liberty, to purchase a little temporary
Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin
Jeff Templon
: In article <3pt5i3$h...@senator-bedfellow.MIT.EDU>, tem...@studbolt.mit.edu
: (Jeff Templon) writes:
: |>those of us who do. You'll just force us to write lots and lots of
: |>code which relies on all those DEC extensions you're trying to
: |>purge out of the language. I guess DEC understands that sometimes
: |>people actually want to do something with the hardware, and need
: |>high performance.
: Not that I disagree with your basic position that you need features that
: give you access to the best performance, but I feel I must point out that
: none of the features Phillip has listed as "not needed" are DEC extensions.
: In the text of your posting you mentioned STRUCTURE/RECORD - F90 has
: derived types which, for the most part, can be used to replace
: STRUCTURE/RECORD, but I have never seen ANYONE suggest that STRUCTURE/RECORD
: was poor programming practice.
Sorry, I was not specific enough. What I meant by DEC extensions was
for example DECs UNION/MAP pair in structures. Indeed, UNION/MAP
severely reduces the load on EQUIVALENCE. However, first of all
if you want your stuff to be contiguous in memory, you need to
specify the SEQUENCE qualifier in the TYPE def, and all the f90
books I've seen (three so far) warn again against dangerous and
unnecessary programming practice.
Unfortunately, there is no F90 equivalent that I have seen for
UNION/MAP within a TYPE def. This is what I was referring to
when I said I'd be using DEC extensions, since given the reservations
over SEQUENCE, I can't see UNION/MAP going into F95.
JT
Steve Lionel
In article <3puji0$k...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig
<phe...@hs.uni-hamburg.de> writes:
|> continuation symbol at the BEGINNING of the line.
|> This is what I was talking about when I mentioned
|> the legibility of fixed form. I agree that the
|> space business can cause problems, but couldn't one
|> have made spaces significant and put the SIGNIFICANT
|> continuation mark at the beginning of the line?
I'm not sure if you're suggesting that the mark be at the beginning of the
continuation line (sort of as it is in fixed form) or the beginning of the
line to be continued. I'll just comment that as a compiler developer, the
fact that once you've read a source line you don't know if you have to read
another is a pain in the neck. An end-of-line mark is fine with
me and I think looks more natural, as long as we're not going so far as to
introduce end-of-statement delimiters so that continuation marks are
unnecessary (I am *NOT* suggesting this!)
WIlliam B. Clodius
>
> In article <3prr2k$8...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
> [Stuff deleted]
> >
> > > Fixed form source (!)
> >
> > Make that a few more exclamation marks. Someone pointed out that one
> > can make free-form source look ALMOST like fixed-form, but this isn't
> > really the point. Again, WHY should this be declared obsolescent? What
> > I like about FORTRAN is that one can make it really READABLE if wanted.
> To reinforce,
> i) contrary to common views I've found the labelling combined with the fixed
> form to even add readability, iff one adopts some additional conventions,
> like hierarchical naming in DO nests (e.g. 2011>3011,3012>4011, 2021 ...),
> and placing unavoidable GOTOs, ERRs, and such flush right.
To reply:
1) The new do loops allow a different form of DO labelling that can be even
clearer than numeric labelling
2) Most comments to the effect that DO loop numeric labelling is usefull
involves loops extending over several pages. A practice that results in and
of itself in difficult to maintain code, with little if any gain in efficiency.
In other words, numeric labelling is often used as a kludge to partially
compensate for a bad overall coding style. Such problems are best addressed
mor directly and not papered over. If this is your practice or the practice
of others you work with, I encourage setting a requirement that any procedure
whose body extends more than 50 lines of text have a written justification.
3) With EXIT, CYCLE, and SELECT CASE the most common reasons for having
GOTO's is eliminated. With IOSTAT the other major reasons for numeric
labels, ERR and END, has been eliminated.
> ii)Some F77 code may have been laid out including non-standard pre-processing
> controls in columns 73 thru 80, e.g. an Ocean General Circulation Model
> of size some 50,000 lines which I work with but have not written myself.
> [Stuff deleted]
This is a more difficult problem to address. Most reasons for pre-processing,
but not all, have been relmoved in F90 by making many common extensions
standard. Other preprocessors now exit that are reliable and do not require
use of column past column 72, but convering the code to eliminate unnecessary
preprocessing statements and convert to a different preprocessor is not
a task to be undertaken lightly.
Steve Lionel
In article <3q23af$k...@senator-bedfellow.MIT.EDU>, tem...@studbolt.mit.edu
Ok, I see your point (and sympathize). I suspect the reason there's no
UNION/MAP is that that would prevent you from doing formatted I/O on
derived types, among other things. But if you could live with that
restriction (as you do already using STRUCTURE/RECORD), it would be nice
to add.
The warnings about SEQUENCE come from a desire to keep programs
as isolated as possible from the underlying machine representation. In
general this is fine, but not when you have applications like yours which
communicate with external hardware (or need to know the layout of bits on
disk.)
Fortunately for you, you can have it both ways. Use the nice F90 features
where you want, use extensions like STRUCTURE/RECORD (with UNION/MAP) where
you need to. DEC Fortran 90 supports them both, and I imagine that many
other F90 compilers will or do already. And don't worry about deleted or
obsolescent features. It's up to you to decide whether or not to use them.
Your compiler (especially if it's DEC Fortran 90) will continue to support them.
Thomas Koenig
>Why do you need any statement functions when you always can write a "real"
>function (subroutine) ?
>I don't see any need for statement functions and have never used any...
Better possibility of inlining.
--
Thomas Koenig, Thomas...@ciw.uni-karlsruhe.de, ig...@dkauni2.bitnet.
The joy of engineering is to find a straight line on a double
logarithmic diagram.
Jeff Templon
: other F90 compilers will or do already. And don't worry about deleted or
: obsolescent features. It's up to you to decide whether or not to use them.
: Your compiler (especially if it's DEC Fortran 90) will continue to support them.
Unfortunately I'm running on a Linux box. A fantastic beast in all
respects, except for the Fortran compiler (NAG at the moment; there
are rumours that a significant improvement in NAG is on the way,
which is native output.) NAG supports pretty much vanilla F90.
JT
Carlos A. Felippa
from my experience (with Fortran and other languages) since 1964:
1) Inclusion of high level OOP features will likely
bloat further language versions and compilers.
2) It would be more effective to provide LOW-LEVEL capabilities
to support customized preprocessors that people and teams
interested in OOP extensions may develop if so desire.
3) In my experience the relative importance of OOP features such
as direct and multiple inheritance, polymorphism, agents, etc,
strongly depends on the application. Furthermore many
applications, scientific or otherwise, do not benefit from
those features. Mixed language configurations can take care
of some extreme needs if interfaces are well defined as
suggested below.
4) Among important low level capabilities I would like to see
standardized:
typeless data structures (byte arrays)
block I/O (files as byte sequences)
function arrays and dispatch tables
pragmas for interface to other languages and APIs
well defined interface to communication protocols (MPI, ..)
inlining directives
5) Lessons from use of OO preporcessors might be eventually folded
in the core language, just like RATFOR and Co influenced F77.
About half of F90 is technically obsolete, and I applaud the effort
to clean up the syntax and interfaces. But I view the trend
away from hardware with some alarm because that had always been a
strong point of the language.
Similarly the decision to force everything into a backward-compatible
language, without consideration of preprocessor solutions, was
personally discouraging. Scores of geriatric features such as H-formats,
dotted logical operators, and fixed source could have been dropped
from F90 by moving them to a STANDARD-SPECIFIED preprocessor with the
ability to convert the dusty decks once and for all. The next window
of opportunity for leanness is coming up.
Harald Anlauf
In article <3q1i0s$g...@fg70.rz.uni-karlsruhe.de> ig...@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
In comp.lang.fortran, se...@rankki.kcl.fi (Tero . Tommila) wrote:
>> Why do you need any statement functions when you always can write a "real"
>> function (subroutine) ?
>> I don't see any need for statement functions and have never used any...
Thomas> Better possibility of inlining.
I would gladly sacrifice statement functions if there were a
PREPROCESSOR defined in the standard. Then I would even sacrifice
parameter statements.
--
Ciao,
-ha
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Harald Anlauf | Phone: +49-6151-16-2972 (office)
TH Darmstadt | +49-6151-714673 (private)
Institut f. Kernphysik | Fax: +49-6151-16-2421
Schlossgartenstr. 9 | Internet: anl...@crunch.ikp.physik.th-darmstadt.de
64289 Darmstadt | Harald...@cern.ch
Germany | anl...@slac.stanford.edu
Phillip Helbig
>In article <3puji0$k...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>> In <3prr2k$8...@rzsun02.rrz.uni-hamburg.de> Phillip Helbig <phe...@hs.uni-hamburg.de> writes: Yes, that was I!
>>
>> >I guess that this is the best place for some fruitful discussion on this
>> >topic; it seems that there is still time to make some changes. I would
>> >appreciate as much feedback as possible. If the bandwidth looks too large,
>> >or the subject matter is a bit off the mark, feel free to send me email.
>> >Be just as verbose whether you agree or disagree with my comments!
>>
>> Just adding a few comments, based on email responses and postings, to clarify
>> some points and keep the discussion fruitful.
>>
>>
>> >>Obsolescent:
>>
>[snip]
>> >> Real and double precision DO variables
>Could someone point out the reason for this being Bad?
Round off error in calculating the number of times to go through
the loop , producing unexpected results and machine dependence.
Phillip Helbig Tel. .............. +49 40 7252 4110
Hamburger Sternwarte Email .... phe...@hs.uni-hamburg.de
Gojenbergsweg 112 Fax ............... +49 40 7252 4198
D-21029 Hamburg Telex ............... 217884 hamst d
Phillip Helbig
>In <3prr2k$8...@rzsun02.rrz.uni-hamburg.de> Phillip Helbig <phe...@hs.uni-hamburg.de> writes:
>>> Statement functions
>>Could be done more elegantly, perhaps, with MODULE, PRIVATE and so on.
>>What, however, is the REASON why statement functions are to be branded
>>obsolete? I kind of like them myself, and wouldn't like to see them go
>>without a real reason.
>Why do you need any statement functions when you always can write a "real"
>function (subroutine) ?
>I don't see any need for statement functions and have never used any...
>
In the past, the reason was less the compactness---a statement function
is what is called a macro in some other contexts---but rather the fact that
it is only defined in one program unit. F90 can get this functionality
with the internal subroutine concept (CONTAINS, PRIVATE and what not).
Phillip Helbig
>In article <3puji0$k...@rzsun02.rrz.uni-hamburg.de>, Phillip Helbig
><phe...@hs.uni-hamburg.de> writes:
>|> & at end of line --- it would be more practical to have the SIGNIFICANT
>|> continuation symbol at the BEGINNING of the line.
>|> This is what I was talking about when I mentioned
>|> the legibility of fixed form. I agree that the
>|> space business can cause problems, but couldn't one
>|> have made spaces significant and put the SIGNIFICANT
>|> continuation mark at the beginning of the line?
>I'm not sure if you're suggesting that the mark be at the beginning of the
>continuation line (sort of as it is in fixed form) or the beginning of the
>line to be continued. I'll just comment that as a compiler developer, the
>fact that once you've read a source line you don't know if you have to read
>another is a pain in the neck. An end-of-line mark is fine with
>me and I think looks more natural, as long as we're not going so far as to
>introduce end-of-statement delimiters so that continuation marks are
>unnecessary (I am *NOT* suggesting this!)
At the beginning of the continuation line, sort of like in fixed form.
I see your point as far as making it easier for the compiler. However,
when scanning through code, if the continuation line is marked at the
beginning, rather than at the end of the previous line, one sees right
away whether a line is a continuation, or a new statement. This is
easier than looking at the end of the previous line. Perhaps requiring
BOTH would be a good idea.
Phillip Helbig
>clearer than numeric labelling
>2) Most comments to the effect that DO loop numeric labelling is usefull
>involves loops extending over several pages. A practice that results in and
>of itself in difficult to maintain code, with little if any gain in efficiency.
>In other words, numeric labelling is often used as a kludge to partially
>compensate for a bad overall coding style. Such problems are best addressed
>mor directly and not papered over. If this is your practice or the practice
>of others you work with, I encourage setting a requirement that any procedure
>whose body extends more than 50 lines of text have a written justification.
My original comments about fixed-form source---since appended---have
nothing to do with labels. If one takes a really structured approach
to programming, blocks can become long. The possibility of NAMING
DO loops (and IF blocks!!!) in F90 is even better than labels for clarity
in this regard.
Craig Dedo
>Similarly the decision to force everything into a backward-compatible
>language, without consideration of preprocessor solutions, was
>personally discouraging. Scores of geriatric features such as H-formats,
>dotted logical operators, and fixed source could have been dropped
>from F90 by moving them to a STANDARD-SPECIFIED preprocessor with the
>ability to convert the dusty decks once and for all. The next window
>of opportunity for leanness is coming up.
In developing F90, X3J3 and the ISO decided upon a two-stage method of
removal of obsolete features from the language. In this model, a feature is
first targeted by putting it on the obsolete list. Only after it has been
on the obsolete list for AT LEAST one standard cycle, can it be deleted from
the language. This is so that programmers have ample warning that they are
using a feature that may eventually be deleted from the language.
Your proposed process would give programmers NO warning.
Why the concern about leanness? Once a feature is in the language, no work
needs to be done to keep it there. It takes work to remove a feature from
the language. As a practical matter, almost all Fortran compilers of any
note retain deleted features because the customers of these compilers want it
that way.
Personnally I consider leanness to be of little importance. Far, far more
important is giving our customers the features that they want and need so
that they can write practical applications that are truly useful. And write
these applications in a straightforward, easily understood manner that
increases human software productivity without having the programmer resort
to subtle tricks and contortions in order to get the job done.
Craig Burley
Why the concern about leanness? Once a feature is in the language, no work
needs to be done to keep it there. It takes work to remove a feature from
the language. As a practical matter, almost all Fortran compilers of any
note retain deleted features because the customers of these compilers want it
that way.
I'd say it takes more work to keep some features in than remove them.
In fact, I think that's one of many important indicators of whether
a feature is a candidate for removal. If removing it is easier than
trying to understand how it should/shouldn't interact with all the other
newer features, then it should be at least considered for removal (by
making it obsolescent, then removing it in a later standard, etc.).
The problem with various "old" features is that while they may have had
directly understandable effects when used in "vanilla" (standard-conforming)
mode, they are often necessarily used in various other flavors that
have vendor-specific behaviors, e.g. when interacting with other language
features or extensions.
Typically in language design and evolution, we have to "concede" this
kind of non-standard use with the attitude "well, we don't want to define
the behavior you get by using these features at the language level because
it's pretty implementation-specific; we can't yet, for whatever reasons,
provide all the necessary new features allowing you to express your
needs in a portable way; and we don't want to remove the few standard-
conforming crutches you need gratuitously, at least until the new features
have been available and shown to be adequate replacements for your needs".
For example, COMMON/EQUIVALENCE and type-mixing; there's a lot of code
that "needs" to combine CHARACTER and non-CHARACTER data. Not allowing
that combination is, from the point of view of language design alone,
a pretty bad kludge -- why is mixing of other types allowed but this
exception is made? -- but from the point of view of providing reasonably
portable (non-system-specific) behavior while still allowing its use
to express the various needs for which this combining is often used is,
in fact, impossible. One could as easily argue that all type mixing
should have been disallowed by F77 -- in fact, it isn't supported in
the "ideal" to-the-iron manner on all systems, such as those that can't
align DOUBLE PRECISION variables on arbitrary REAL-aligned boundaries,
which is required by F77, without sacrificing performance even when
accessing those DOUBLE PRECISION variables that happen to be ideally
aligned. (As I recall, the Sun Sparc architecture is an example of
this -- ldd and std are the fast ways to access DOUBLE PRECISION, but
cannot be safely used if the alignment isn't satisfied, so you must
compile all your stuff without using those instructions if you sometimes
need F77-conforming-but-Sparc-unhappy alignment, affecting performance
on even happily aligned values.)
But as other language features are added and mature, decisions must
be made about COMMON/EQUIVALENCE. You say just keeping such features
isn't any or much work, yet look how much complaining has been done
because things like COMMON/EQUIVALENCE, statement functions, and so
on have _not_ been enhanced to work more orthagonally with newer
language features. E.g. why can't I pass a statement function to
another procedure? That is a reasonable question even in F77. But
making the old features relevant vis-a-vis all the new ones can
take more work than designing the new ones!
In language evolution, it turns out to be necessary to try reasonably
hard to deprecate what I call the "prickly" features -- the features
that stand out, increasingly, due to their non-orthagonality as other
features are added/improved in orthagonal ways -- so that the language
_as used by most of its users_ increases its expressive power without
significantly increasing its porcupine nature. But to be done
successfully, the prickly features must have already been almost entirely
subsumed by other, more orthagonal features. (E.g. a major use of
COMMON/EQUIVALENCE has actually been subsumed by the user-defined-
TYPE mechanism...but that doesn't nearly "almost entirely" subsume
COMMON/EQUIVALENCE.)
IMO, not being much of an expert on how Fortran is actually used day-to-
day, the jury is still out on how well F90 has succeeded in subsuming
the prickly features. My take on it is that it hasn't been that
successful, and that even people who really really try to write
serious F95/F2000 code without using removed features will be fought
in various ways. (I think fixed-form actually is a better candidate
for successful removal, according to my views, than most other things
being proposed...another exception is computed-GOTO, which, while I
love the conciseness, I suspect that it is becoming quite unlikely
that the equivalent, clearer SELECT CASE is typically much slower to
compile or even marginally slower to execute at run time.)
For example, I agree statement functions are poorly designed in various
ways in Fortran, and should someday be removed, even though there will
likely never be as _concise_ a way to express them in most cases (and
that's just the way things go; concise expression is often shown to be
an advantage of prickly features, in fact a driving force for them, but
it also is often shown to be a way of writing buggy code that looks like
it should work).
But, statement functions aren't even close to being subsumed in terms
of their other advantages. I consider them to be ready for deletion
when nearly everyone is using a Fortran development environment that is
of sufficiently radical design or sheer speed that the difference in
compile-time and run-time performance between
PROGRAM FOO
TWICE(R) = 2. * R
...lots of code, with invocations of TWICE(expr)...
END
and
PROGRAM FOO
...lots of code, with invocations of TWICE(expr)...
CONTAINS
FUNCTION TWICE(R)
TWICE = 2. * R
END FUNCTION TWICE
END
become non-existent. (The former is more concise, but I think the latter
is easier will be more reliably understood by F90-aware readers than the
former is by F77-aware readers, who sometimes confuse the statement-function
definition with an assignment, etc.). MODULEs certainly subsume a
portion of statement-function usage, and offers (given newer compiler
technology) a much better replacement for them, but not for cases like
the above.
The kinds of things that need to happen _could_ be made to happen more
quickly had F90 allowed the latter example to be coded this way:
PROGRAM FOO
CONTAINS
FUNCTION TWICE(R)
TWICE = 2. * R
END FUNCTION TWICE
END CONTAINS
...lots of code, with invocations of TWICE(expr)...
END
I.e. had allowed CONTAINS to be used an arbitrary number of times and
either before or after other code. (In which case CONTAINS/END CONTAINS
probably isn't the best syntax, but it gets the idea across for the
purposes of this post.) That way, a compiler can, in its first pass,
get an idea of whether TWICE is an internal function, whether its
likely to be inlinable, tell whether its invocations are in accord
with its definition, and so on, which can be a big time-saver compared
with the need to get to the second pass.
I know lots of people "theorize" that faster compilers, machines, new
ways of compiling can make the above "problem" irrelevant, and I tend
to agree, but I happen to also believe that until this theory is
reduced to ordinary practice and used by most of the target audience,
the problem isn't solved.
In fact, I would have preferred that, among perhaps other things,
F90 _required_ specification of the interfaces of all CONTAINed
(internal) procedures before any code in the outer procedure (or
any specification statements that use the procedures), because in
its current form, it allows code like the first F90 example above
that clearly requires a second pass before even _diagnostics_
about invalid reference to TWICE can be produced.
Again, theoretically, diagnostics _can_ be produced as fast or faster
using new compilation paradigms, and there are plenty of diagnostics
that probably could not be produced until into the second pass anyway...
but in _practice_ I, for one, would be much less productive if, say,
gcc happened to "save up" all its diagnostic messages until it was
done processing an entire file and then dumped them all at once, because
I watch the compile, and as soon as I see a diagnostic, I might well
start working on fixing it.
So IMO statement functions cannot yet be deleted, because they haven't
been adequately replaced.
BTW, another example of why I think the post-reference-CONTAINS is
the wrong way to go is to imagine what will happen if Fortran someday
allows arrays of functions (pointers to function, in C lingo). Which
do readers have an easier time grasping?
PROGRAM FOO
FOO(R) = 3.*R
BAR(R) = 4.*R
BLETCH(R) = 5.*R
FUNCTION, DIMENSION(3) :: A = /( FOO, BAR, BLETCH /)
...tons of code, which can invoke A(N) or pass it, &c...
END
Or:
PROGRAM FOO
FUNCTION, DIMENSION(3) :: A = /( FOO, BAR, BLETCH /)
...tons of code, which can invoke A(N) or pass it, &c...
CONTAINS
FUNCTION FOO(R)
FOO = 3.*R
END FUNCTION FOO
FUNCTION BAR(R)
BAR = 4.*R
END FUNCTION BAR
FUNCTION BLETCH(R)
BLETCH = 5.*R
END FUNCTION BLETCH
END
I think the requirement that the FOO, BAR, BLETCH names be defined
way after they are used to specify initial values for A asks for
maintenance challenges. Allowing the CONTAINS block to be moved
to before the initial assignments to A would solve that problem.
But that's a different issue...I happen to be most comfortable
with coding such that one tends to look _up_ in the source file
to find definitions for things one sees referenced, rather than
having to look _down_ (though that isn't always perfect). Not
everyone feels that way. I do wonder why Fortran is half-headed
in that direction, though...if it's now considered wrong to
put DATA statements in among/after executables (and, remember, that
in F77 they were _by definition_ in among them, in that they
followed all specification statements), why is it not
considered wrong to put CONTAINS blocks after executable
statements? Sigh.
--
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
WIlliam B. Clodius
The difference between putting a continuation marker at the beginning
vs. at the end of the line is the difference between noting whether a
statement is continued or is a continuation. In either case additional
hints can be given to the reader by a coding style, e.g. e.g ending or
starting appropriate lines with operators or parentheses. However most
code is typically executable statements, for which, in the majoritiy of
cases, it is obvious from syntax that a line is a continuation, e.g.
if it doesn't have an assignment operation, or a CALL etc., but it is
often not obvious that a line is continued, i.e., in
A = a_long_set_of_terms ! may appear complete (unless terminated by
! an operator )
* another_set_of_terms ! will not appear complete even if the
! operator is missing
In most other cases both the initial and continued line will be seen to
be incomplete with a little study, e.g.
REAL, POINTER, DIMENSION ... !this will not define a variable
... :: X ! This does not give the variable's type, if IMPLICIT NONE
! is used
Note also that typically further lines are read in order, not at random, and
without the continuation marker at the end there is a small amount of
surprise in going to the next line and finding that it is continued, vs.
seeing that subsequent lines need to be examined before understanding the
implications of the present line of a set of statements.
Michel OLAGNON
>>>>>> "Thomas" == Thomas Koenig <ig...@fg70.rz.uni-karlsruhe.de> writes:
>In article <3q1i0s$g...@fg70.rz.uni-karlsruhe.de> ig...@fg70.rz.uni-karlsruhe.de (Thomas Koenig) writes:
>In comp.lang.fortran, se...@rankki.kcl.fi (Tero . Tommila) wrote:
>>> function (subroutine) ?
>>> I don't see any need for statement functions and have never used any...
>
>
>I would gladly sacrifice statement functions if there were a
>PREPROCESSOR defined in the standard. Then I would even sacrifice
>parameter statements.
>--
As you may know, I wrote such a pre-processor, which I believe is reasonably
debugged now.
It is freely available from
ftp://ftp.ifremer.fr/ifremer/ditigo/fortran90/f90ppr.f90.gz
As noted in a recent Fortran Journal article, it took me about one month
to write it.
I fear that if I wanted the specs of such a preprocessor to be published
as a collateral standard, it would take me much more in the order of one
man-year, extending over several actual years. Neither I, nor my boss, are
ready to spend that much time on standardization issues, but I would
certainly support anyone that wants to undertake that task.
Michel
--
| Michel OLAGNON email : Michel....@ifremer.fr|
| IFREMER: Institut Francais de Recherches pour l'Exploitation de la Mer|
| Centre de Brest - B.P. 70 phone : +33 98 22 41 44|
| F-29280 PLOUZANE - FRANCE fax : +33 98 22 41 35|
Kate Hedstrom
>I would gladly sacrifice statement functions if there were a
>PREPROCESSOR defined in the standard. Then I would even sacrifice
>parameter statements.
The C to C++ trend is to use "const" and inline functions rather than
using the C preprocessor because you get type checking. If you use
implicit none, then both statement functions and parameters are type
checked. I use the C preprocessor, but only for "#ifdef SOMETHING"
and for a crude typedef. I want the type checking of parameters and
statement functions.
Kate
Paul J. Gooderham
>
> DO 10 X = 0.0, 1.0, 0.1
>
Who cares?
The programmer doesn't, he explicitly said so.
--
Paul J. Gooderham pjgoo...@vnet.ibm.com
@>--,--`---,----- Enjoy the Silence
Roger Glover
In article <3qflol$5...@cosine.torolab.ibm.com>, pjgoo...@vnet.ibm.com (Paul J. Gooderham) writes:
> In article <danpop.801400643@rscernix>, Dan Pop <dan...@afsmail.cern.ch> wrote:
> >
> > DO 10 X = 0.0, 1.0, 0.1
> >
> >How many times is this loop executed ... ?
>
> Who cares?
Perhaps those who care are the poor folks left holding the bag after
this so-called "programmer" has done his worst.
> The programmer doesn't, he explicitly said so.
"Programmer," like "minister," "engineer," and "secretary," can take
on a wide variety of connotations. The "programmer" who doesn't care
about program correctness (and hence, ability to verify program
correctness), is only a programmer in the most vulgar sense. That
is, he/she is writing a computer program ... period.
In many cases, the Fortran standard attempts to limit the validity of
programmer behavior without stopping the behavior altogether. In
such cases it warns the programmer of "undefined program behavior."
This is usually done in the name of optimization. Such is *not* the
case here.
An example. BEFORE:
DO 10 X = 0.0, 1.0, 0.1
...
10 CONTINUE
AFTER:
X = 0.0
DO 20 IX = 0, 10
...
X = X + 0.1
10 CONTINUE
The "AFTER" loop is guaranteed by the standard to behave the same way
on all systems (flame-retardant below**). The "BEFORE" loop is
not. That is why we *should* care, even if the "programmer" does not.
Aside from program correctness, the remaining issues for deciding
whether or not to remove this from the standard are:
- What can you do with the "BEFORE" loop that you cannot do with
the "AFTER" loop? (Ensure job security?)
- An F90 "DO WHILE" loop (or F90 "blank DO") can be used to
implement the "BEFORE" loop behavior if it is truly
desired. What can the "BEFORE" loop do that such a loop
cannot? (nothing IMO)
- What optimization advantage could there be for the "BEFORE"
loop that is not shared by the "AFTER" loop or an
equivalent "DO WHILE"?
- What change would it have on existing code? (almost none
IMO, since all of us vendors will continue to implement it
anyway)
----------------------------------------------- Roger Glover
XXXX\ \ / \ /XXX \ / \ X \ /\\\ X///X /\\\ Cray Research, Inc.
/ \ / \/ /\ / \ / \X /\ X \ / \ X\ \ X DISCLAIMER HAIKU:
//X/ X\\\X //X/ X \ X X\\ / \ X/X \ X \\\ C R I may not
/ \ X///X / \/ X//XX X \ / \ X \\ X \ Share these opinions with me
/ \ X X /\\\/ X X X///X /XXX/ X///X /XXX/ This is not my fault
-----------------------------------------------
** Barring floating point numerical differences in results and
machine-specific ways of jumping out of the loop (testing reals
for equality, etc.). I hate talking like a lawyer.