ELF90 and Derived Type Constructor (in a Module)
Walt Brainerd
Bob Greer <bo...@humboldt.net> wrote:
> Will ELF90 compile a constructor for a derived type?
I don't have ELF90, so can't answer this for sure,
but I suspect so (see below).
> ELF90 output says: "Essential LF90 does not support declaring type on the
> function statement" when it compiled my equivalent code (below).
>
> I interpreted this to mean ELF90 won't support standard constructor syntax,
> and I found no details about functions (with derived-type results) in the
> ELF90 supporting literature.
I would gess it means just what it says: you can't put the type on the
function statement, but need to type the function within the function.
I.e., change
TYPE(Coords_3D) FUNCTION Init_Coords_3D(x,y,z)
to
FUNCTION Init_Coords_3D(x,y,z)
TYPE(Coords_3D) :: Init_Coords_3D
This is one more example of multiple ways of doing things in Fortran
and F also does no allow typing on the function statement.
--
Walt Brainerd wa...@fortran.com
Unicomp, Inc. +1-505-797-8989 797-3251 (fax)
2 San Rafael Ave NE, Suite C +1-500-Fortran (367-8726)
Albuquerque, NM 87122 USA http://www.fortran.com/fortran
Bob Greer
Will ELF90 compile a constructor for a derived type?
I want a constructor for a derived type that is declared in a in a module.
The constructor is a module function, of course, so I shouldn't need an
interface block.
This example of a derived-type constructor is from High-Performance Fortran
Programming by
Dr. AC Marshall:
TYPE(Coords_3D) FUNCTION Init_Coords_3D(x,y,z)
REAL, INTENT(IN), OPTIONAL :: x,y,z
<SNIP>
END FUNCTION Init_Coords_3D
ELF90 output says: "Essential LF90 does not support declaring type on the
function statement" when it compiled my equivalent code (below).
I interpreted this to mean ELF90 won't support standard constructor syntax,
and I found no details about functions (with derived-type results) in the
ELF90 supporting literature.
Any suggestions are welcome!
------------------------------
! This is a DUMMY CONSTRUCTOR FOR DEFINED TYPE Type_Record_A
! (The guts go in later)
! Input: a file unit number
! Output: initialization data for a record of type Type_Record_A.
TYPE(Type_Record_A) FUNCTION init_record_A( unit_number )
integer, intent(in) :: unit_number
<SNIP>
stop
end subroutine init_record_A
Bob Greer
Bear Mountain Cartography
POB 142, Phillipsville CA 95559 USA
http://humboldt.net/~bobg/
Bob Greer
The Derived-Type Constructor & ELF90 problem disappeared w/o warning;
spurious error message or?
But thanks anyway!
- Bob
@ozemail.com.au Alan Miller
ELF90 does support derived types - it does not support:
(type) FUNCTION xyz( args )
You must use:
FUNCTION xyz( args ) RESULT( output )
TYPE( Coords_3D) :: output
--
Alan Miller, Retired Scientist (Statistician)
CSIRO Mathematical & Information Sciences
al...@vic.cmis.csiro.au, mill...@ozemail.com.au
http://www,ozemail.com.au/~milleraj
Bob Greer <bo...@humboldt.net> wrote in article
<01bcb750$e490e8e0$3141b8ce@bobg>...
James Giles
Walt Brainerd <wa...@swcp.com> wrote in article <5uhbi6$9...@boofura.swcp.com>...
> I would gess it means just what it says: you can't put the type on the
> function statement, but need to type the function within the function.
> I.e., change
>
> TYPE(Coords_3D) FUNCTION Init_Coords_3D(x,y,z)
> to
> FUNCTION Init_Coords_3D(x,y,z)
> TYPE(Coords_3D) :: Init_Coords_3D
>
> This is one more example of multiple ways of doing things in Fortran
> and F also does no allow typing on the function statement.
It is interesting that both of the subset languages (which supposedly
cut out functionality that is archaic or confusing) have opted *not* to
allow a function's type on the FUNCTION statement (where it's
much clearer). If I were writing a subset, or an extension of a
subset (that is, not all the features of F90, but some additional
ones instead), I would not permit the type of a function to be
specified any other way.
Of course, I would also like to see the argument types specified in
the FUNCTION (or SUBROUTINE) statement as well. Then the
initial statement serves, by itself, as a reasonable synopsis of the
procedure's type and usage.
--
J. Giles
Ricercar Software
fair...@sldb4.slac.stanford.edu
In article <01bcb801$4c3d5fe0$6c7793cf@default>,
"James Giles" <james...@worldnet.att.net> writes:
[...]
> It is interesting that both of the subset languages (which supposedly
> cut out functionality that is archaic or confusing) have opted *not* to
> allow a function's type on the FUNCTION statement (where it's
> much clearer). If I were writing a subset, or an extension of a
> subset (that is, not all the features of F90, but some additional
> ones instead), I would not permit the type of a function to be
> specified any other way.
>
> Of course, I would also like to see the argument types specified in
> the FUNCTION (or SUBROUTINE) statement as well. Then the
> initial statement serves, by itself, as a reasonable synopsis of the
> procedure's type and usage.
While I generally agree with your sentiments, isn't the issue
here that type declaration statements have gotten _much_ more
complicated in F90/95? There are all sorts of attributes you might
want to assign to a function return value that would be difficult to
include in the FUNCTION statement itself (unlike a simple INTEGER or
REAL type specifier). Similarly, allowing the argument type
declarations in the FUNCTION or SUBROUTINE statement could be very
difficult to read, let alone parse.
I'll admit to _preferring_ to include the type as part of the
FUNCTION declaration in F77: I too find it more readable since it
puts the critical information right up front. But I can also
understand limiting its use (or eliminating it?) in F90/95.
-Ken
--
Kenneth H. Fairfield | Internet: Fair...@Slac.Stanford.Edu
SLAC, P.O.Box 4349, MS 46 | DECnet: 45537::FAIRFIELD (45537=SLACVX)
Stanford, CA 94309 | Voice: 650-926-2924 FAX: 650-926-3515
-------------------------------------------------------------------------
These opinions are mine, not SLAC's, Stanford's, nor the DOE's...
Ralph Jay Frisbie
James Giles wrote:
>
> Walt Brainerd <wa...@swcp.com> wrote in article <5uhbi6$9...@boofura.swcp.com>...
> > I would gess it means just what it says: you can't put the type on the
> > function statement, but need to type the function within the function.
> > I.e., change
> >
> > TYPE(Coords_3D) FUNCTION Init_Coords_3D(x,y,z)
> > to
> > FUNCTION Init_Coords_3D(x,y,z)
> > TYPE(Coords_3D) :: Init_Coords_3D
> >
> > This is one more example of multiple ways of doing things in Fortran
> > and F also does no allow typing on the function statement.
>
> cut out functionality that is archaic or confusing) have opted *not* to
> allow a function's type on the FUNCTION statement (where it's
> much clearer). If I were writing a subset, or an extension of a
> subset (that is, not all the features of F90, but some additional
> ones instead), I would not permit the type of a function to be
> specified any other way.
>
> Of course, I would also like to see the argument types specified in
> the FUNCTION (or SUBROUTINE) statement as well. Then the
> initial statement serves, by itself, as a reasonable synopsis of the
> procedure's type and usage.
>
> J. Giles
> Ricercar Software
And that's why clean small languages are created by a very small group
of people working closely together; whenever a large committee
representing
a large sprectrum of interests get together to define/extend a
language, many
diverse and well reasoned approaches and capabilities get defined,
requested,
demanded. If the further requirement is added of backwards
compatibility to
previous such compromises and decisions, the result is full F90.
ELF90 was a few people at Lahey, F a few at Imagine1. Other languages
which started 'cleanly' would include C, Pascal, even BASIC. But then
people
and vendors start adding 'features' and language bloat sets in.
Please do not consider this comment a criticism of your suggestion,
Mr. Giles, but rather a commentary on language inflation.
--
_______________________________
| Ralph Jay Frisbie |
| |
| a saucer lover, |
| but not the inventor! |
| |
| rfri...@vcnet.com |
| 805-671-9989 |
|______________________________|
James Giles
Ralph Jay Frisbie <rfri...@vcnet.com> wrote in article
<3418B0...@vcnet.com>...
> And that's why clean small languages are created by a very small group
> of people working closely together; whenever a large committee
> representing
> a large sprectrum of interests get together to define/extend a
> language, many
> diverse and well reasoned approaches and capabilities get defined,
> requested,
> demanded. If the further requirement is added of backwards
> compatibility to
> previous such compromises and decisions, the result is full F90.
> ELF90 was a few people at Lahey, F a few at Imagine1. Other languages
> which started 'cleanly' would include C, Pascal, even BASIC. But then
> people
> and vendors start adding 'features' and language bloat sets in.
> Please do not consider this comment a criticism of your suggestion,
> Mr. Giles, but rather a commentary on language inflation.
Yes, I've long been of the opinion that committees cannot do good
(or even reasonable) language design work and should be restricted
to codifying widespread existing practice. That kind of restriction
to committees has long fallen by the wayside though.
Walt Brainerd
James Giles <james...@worldnet.att.net> wrote:
> Yes, I've long been of the opinion that committees cannot do good
> (or even reasonable) language design work and should be restricted
> to codifying widespread existing practice. That kind of restriction
> to committees has long fallen by the wayside though.
If X3J3 had chosen this route, there would be no Fortran 90 as we
know it. There simply was no "widespread existing practice" for
such things as modules, dynamic objects, array processing (there
was some "<narrow>spread existing practice"), optional and keyword
arguments, argument intent, and most of the other important features
of Fortran 90. We would have had F77 + namelist + implicit none
and maybe a couple of other minor things and Fortran really would
be dead now, I think.
However, I will not claim committees can do great language design
either. It is just that there was (is) no real alternative for
Fortran. [F and ELF90 are slightly different topics.]
James Giles
Walt Brainerd <wa...@swcp.com> wrote in article <5vma1k$i...@kitsune.swcp.com>...
> If X3J3 had chosen this route, there would be no Fortran 90 as we
> know it. There simply was no "widespread existing practice" for
> such things as modules, dynamic objects, array processing (there
> was some "<narrow>spread existing practice"), optional and keyword
> arguments, argument intent, and most of the other important features
> of Fortran 90. We would have had F77 + namelist + implicit none
> and maybe a couple of other minor things and Fortran really would
> be dead now, I think.
This assumes that users and vendors would have been idle if there
had *not* been a standard in the offing. I believe that to be unrealistic.
There were, in fact, moves to provide most, or all of these features
in various implementations. But these efforts were resisted by
vendors who adopted a "let's wait and see what the standard says"
attitude. Fortran developed faster, and with better features, when
vendors and the users community were more adventurous.
This same trend is now happening to other languages (C/C++ for
example) which experienced more robust growth (in both features
and popularity) *before* there were standards committees for
them.
If all language committees adopted a rule of no new design - only
codifying existing practice - the onus would be on the vendor and
user communities to be creative. The language standard could then
adopt the best of the best. What we get instead are features which
no one has long experience with and no one (not even the designers)
can be sure whether they are enhancements to the language or
liabilities. And, we get features in each of those two categories.
Richard Maine
"James Giles" <james...@worldnet.att.net> writes:
> Walt Brainerd <wa...@swcp.com> wrote in article <5vma1k$i...@kitsune.swcp.com>...
> > If X3J3 had chosen this route, there would be no Fortran 90 as we
> > know it. There simply was no "widespread existing practice" for...
>
> This assumes that users and vendors would have been idle if there
> had *not* been a standard in the offing. I believe that to be unrealistic.
Belief's on the matter apparently differ. There is a severe chicken
and egg problem here. I am one user (and I certainly don't represent
all users, but I also know that I am not alone) that refused and would
have continued to refuse to use major non-standard vendor extensions.
Yes, I did break down and use minor f77 extensions like long variable
names and a few others, but I never used things like so-called
VAX records and Cray pointers, for example. I'd have certainy refused
to use non-standard versions of things like modules, array-processing,
and other of the f90 "biggies."
So if users don't demand the features (or even use them) until
they are standardized, and they aren't standardized until they are
in widespread use, then the language would, as Walt says, be dead.
I'd have abandoned it, for one. Much as I like many things about
Fortran, f77 was no longer meeting my needs.
> If all language committees adopted a rule of no new design - only
> codifying existing practice - the onus would be on the vendor and
> user communities to be creative.
Maybe other users, but not me. Nor I'd expect, other users who
are looking at large investments in codes that need to be portable.
Who wants to put such investments into experimental vendor-dependent
features that may not pan out? Therein lies the problem.
--
Richard Maine
ma...@altair.dfrc.nasa.gov
James Giles
Richard Maine <ma...@altair.dfrc.nasa.gov> wrote in article
<ue202ou...@altair.dfrc.nasa.gov>...
> Belief's on the matter apparently differ. There is a severe chicken
> and egg problem here. I am one user (and I certainly don't represent
> all users, but I also know that I am not alone) that refused and would
> have continued to refuse to use major non-standard vendor extensions.
> Yes, I did break down and use minor f77 extensions like long variable
> names and a few others, but I never used things like so-called
> VAX records and Cray pointers, for example. I'd have certainy refused
> to use non-standard versions of things like modules, array-processing,
> and other of the f90 "biggies."
As you point out, there *were* in fact several features in common
use available from various vendors. If the committee had resolved
to codify existing practice instead of design new features, there
was plenty of material for a new standard as early as 1982 (which
is when most observers expected one). So from then on, you would
not have had to avoid IMPLICIT NONE, long variable names, some
form of records, some form of pointers, DO WHILE, CASE, some form
of MODULE, probably even some form of array processing, etc..
> So if users don't demand the features (or even use them) until
> they are standardized, and they aren't standardized until they are
> in widespread use, then the language would, as Walt says, be dead.
> I'd have abandoned it, for one. Much as I like many things about
> Fortran, f77 was no longer meeting my needs.
What would you have switched to that *had* a standard (since you
claim to refuse to use non-standard features)? C? That would be
cutting things pretty close. It wasn't standardized until the late
'80s - and even then there were few standard conforming implementations
until the Fortran standard was itself released (which almost certainly
would have been earlier if they'd forgone the inventiveness of all the
new features). That leaves Ada, Pascal, Common LISP, Algol,
Cobol, and a few others. Which of those would you have chosen
above F77?
> > If all language committees adopted a rule of no new design - only
> > codifying existing practice - the onus would be on the vendor and
> > user communities to be creative.
>
> Maybe other users, but not me. Nor I'd expect, other users who
> are looking at large investments in codes that need to be portable.
> Who wants to put such investments into experimental vendor-dependent
> features that may not pan out? Therein lies the problem.
On the other hand, there are large groups of users to whom portability
is less important than the pragmatic need to get an answer *now* - or
as soon after now as is possible. These people aren't going to refuse
the most effective features available just because some committee
hasn't approved them yet. That's where the impetus for *useful*
change comes from. That appears to be why languages that still
are *without* the benefit of an international standard committee (or,
at least, without a standard as yet) are the ones whose popularity
increases fastest - the features people want are added immediately by
all vendors who want a market share, and *not* only after a committee
has developed a sanctioned version of them.
Ian Chivers
it is the last point that i would like to comment on.
i also teach and support c++ and java. i have too as
it is what my user community want.
i have found that c++ to be a problem across several
platforms. i use
pc borland
pc microsoft
dec vax - dec
dec alpha - dec
sun - gcc
i also have users who have watcom.
over the three years i've had to work support
c++ i've had major problems with templates
on the above platforms.
this is a very powerful language feature of C++
and one that i wanted to teach.
things are getting better, but they still aren't perfect.
i recommend sticking to standard language features unless
absolutely necessary.
as for java things are even worse.
no standard
a variety of versions, even from sun.
a variety of browsers, with different capabilities.
threads on one platform in the java virtual machine
run to completion - they do not time slice.
i am at the sharp end of this being in a user support
environment.
just my 2 cents worth
:-)
ian chivers
computer centre
king's college london
chiba
Richard Maine <ma...@altair.dfrc.nasa.gov> writes:
> Belief's on the matter apparently differ. There is a severe chicken
> and egg problem here. I am one user (and I certainly don't represent
> all users, but I also know that I am not alone) that refused and would
...
But on the whole, are you better off with a decade between major
releases and features taken from committee to FCS w/o prototyping or
have the folks in various communities before standardization made more
substantive progress?
As has been noted, a Standard in progress is a great inhibitor to
implementors (since anything they produce is sure to have to be
undone, yet maintained and a sensible transition of some sort cobbled
up).
But, as you note, many users can't use important new features until
they are "generally" available on many platforms, and some won't/can't
use them until they are part of a codified standard.
Like many hard problems, there probably isn't any easy answer.
--
Keith H. Bierman keith....@Sun.COM| k...@chiba.Eng.Sun.COM
SunSoft Authoring and Development Tools | k...@netcom.com
901 San Antonio Road UMPK 16-304 | k.bi...@computer.org
Palo Alto, California 94303 | 650 786-9296 voice/650 786-9551 fax
<speaking for myself, not Sun*> Copyright 1997
Paul Winalski
Walt Brainerd wrote:
!>
!> James Giles <james...@worldnet.att.net> wrote:
!>
!> > Yes, I've long been of the opinion that committees cannot do good
!> > (or even reasonable) language design work and should be restricted
!> > to codifying widespread existing practice. That kind of !> >
restriction
!> > to committees has long fallen by the wayside though.
!>
!> If X3J3 had chosen this route, there would be no Fortran 90 as we
!> know it.
That's precisely the point. F90 is an abomination.
--PSW
Kenneth Plotkin
In article <5vma1k$i...@kitsune.swcp.com>,
Walt Brainerd <wa...@fortran.com> wrote:
>If X3J3 had chosen this route, there would be no Fortran 90 as we
>know it. There simply was no "widespread existing practice" for
>such things as modules, dynamic objects, array processing (there
[snip]
One can only dream of what might have been. This is exactly what should
have happened. Only after things became common extensions should X3J3
have gotten together to harmonize details.
X3J3 should not be singled out for the sin of becoming a design group
rather than a standards committee. That's becoming widespread. I got the
chair of a committee I'm on really mad at me. I argued (in writing)
that our standard should not contain anything that had not actually been
done and verified to work.
>and maybe a couple of other minor things and Fortran really would
>be dead now, I think.
[snip]
I think it's dead. There's something with the Fortran name now, but it's
not the same. Look at how many posts there are on the topic of converting
F77 to F90. I think they outnumber the Fortran-to-C questions. If code
needs to be converted, then how can it still really be considered to be
the same language?
I'll keep using Fortran, in F77 mode. But I've decided to not learn the
new F90 stuff. Instead, I'm going to see if I'm not too old to learn C++.
If I'm going to have to learn that much stuff, it might as well be in the
form that the majority uses.
Ken Plotkin
Malcolm Cohen
In article <5vqfnk$1...@access1.digex.net>,
Kenneth Plotkin <kplo...@access1.digex.net> wrote:
>Look at how many posts there are on the topic of converting F77 to F90.
I have always found "cp" to be a good tool for converting standard-conforming
Fortran 77 to Fortran 90.
>Organization: Herman Hollerith Fan Club
Surely you must be supporting Fortran 66 then and not Fortran 77, since F77
contains no more Hollerith than F90.
>If code
>needs to be converted, then how can it still really be considered to be
>the same language?
Absolutely - no way is so-called "ANSI C" really "C" at all.
Nor is (any brand of) so-called "C++" the same language as (any other brand of)
"C++"!
>not learn the new F90 stuff
[...]
>learn C++.
The phrase "straining at a gnat but will swallow a camel" springs ineluctably
to mind.
Happy computing!
Cheers,
--
...........................Malcolm Cohen, NAG Ltd., Oxford, U.K.
(mal...@nag.co.uk)
Kenneth Plotkin
In article <5vrg8f$gc$1...@red.nag.co.uk>,
Malcolm Cohen <mal...@sedi8.nag.co.uk> wrote:
[snip]
>Surely you must be supporting Fortran 66 then and not Fortran 77, since F77
>contains no more Hollerith than F90.
[snip]
Never used Fortran 66. I really liked Fortran IV. Tended to run faster
than Fortran 77, too.
>The phrase "straining at a gnat but will swallow a camel" springs ineluctably
>to mind.
I'm not sure what "ineluctably" means, but I have a feeling you're right.
>Happy computing!
While learning C++? I'll give it a try, but I make no promises. :-)
Thanks for the kind thought, though.
Ken Plotkin
Steven G. Kargl
In article <5vqfnk$1...@access1.digex.net>,
kplo...@access1.digex.net (Kenneth Plotkin) writes:
[munch]
>>and maybe a couple of other minor things and Fortran really would
>>be dead now, I think.
> [snip]
>
> I think it's dead. There's something with the Fortran name now, but it's
> not the same. Look at how many posts there are on the topic of converting
> F77 to F90. I think they outnumber the Fortran-to-C questions. If code
> needs to be converted, then how can it still really be considered to be
> the same language?
Converting an f77 program to f90 makes sense (even though f90 is a superset
of f77). I suppose you never wrote a program with large static arrays?
I was given some code that consumed 80 MBytes of memory due to arrays alone,
and I knew for my purposes I only needed about 10 MBytes. I converted by
hand that code to C so that I could use dynamic memory allocation.
> I'll keep using Fortran, in F77 mode. But I've decided to not learn the
> new F90 stuff. Instead, I'm going to see if I'm not too old to learn C++.
> If I'm going to have to learn that much stuff, it might as well be in the
> form that the majority uses.
Has a C++ standard been approved? If so, how many implementations are
conforming?
--
Steve
finger ka...@troutmask.apl.washington.edu
http://troutmask.apl.washington.edu/~kargl/sgk.html
Ian Chivers
almost. have a look at their ftp site
ftp://ftp.maths.warwick.ac.uk/pub/c++/std/
the conformance issue is one i raised in an earlier post
about language inflation. thing's are getting better, but
you still have to be careful.
teaching the language has been difficult as it is often
a problem finding out whether something not quite doing what
you expect is down to ignorance or compiler conformance.
stay away from the older texts.
the problem with java is much worse.
at least with fortran we have a formal agreed definition
and some pretty bright people on this list to help
clarify the issues.
ian chivers
king's college london
Craig Burley
Paul Winalski <wina...@lspace.zko.dec.com> writes:
> That's precisely the point. F90 is an abomination.
Too strong a word, IMO. Especially considering C++, which isn't
even a half-decent language (just an overly finicky tool, like awk,
sed, or perl). At least with F90 you still *know* that "A = B + C"
will modify neither B nor C nor require A to be defined prior to
execution of the statement. And F90 has a concatenation operator,
like all decent languages that offer some degree of support for
strings.
C++ is *almost* a practical joke. And I *almost* fell for it.
Fortran 90 is a much more sincere effort at producing an
improved *language* instead of a catch-all for all sorts of
nifty features. Limiting yourself to a reasonable subset of
F90 is a much more straightforward thing to do than doing so
with C++.
--
"Practice random senselessness and act kind of beautiful."
James Craig Burley, Software Craftsperson bur...@gnu.ai.mit.edu
Ian Chivers
In article <y6g1r1l...@tweedledumb.cygnus.com>, Craig Burley <bur...@tweedledumb.cygnus.com> writes:
> Paul Winalski <wina...@lspace.zko.dec.com> writes:
>
>> That's precisely the point. F90 is an abomination.
>
> Too strong a word, IMO. Especially considering C++, which isn't
> even a half-decent language (just an overly finicky tool, like awk,
> sed, or perl). At least with F90 you still *know* that "A = B + C"
> will modify neither B nor C nor require A to be defined prior to
> execution of the statement. And F90 has a concatenation operator,
> like all decent languages that offer some degree of support for
> strings.
>
> C++ is *almost* a practical joke. And I *almost* fell for it.
> Fortran 90 is a much more sincere effort at producing an
> improved *language* instead of a catch-all for all sorts of
> nifty features.
Limiting yourself to a reasonable subset of
> F90 is a much more straightforward thing to do than doing so
> with C++.
> --
i agree very strongly with the above statement. it is relatively
easy to find a small subset of f90 that will solve a wider range
of numeric problems.
i have found it very difficult to do the same with c++. you
have to know a hell of a lot about the language due to
the syntax of the language.
ian chivers
computer centre
king's college london
>
Israel Gale
kplo...@access1.digex.net (Kenneth Plotkin) writes:
> Look at how many posts there are on the topic of converting
> F77 to F90. I think they outnumber the Fortran-to-C questions. If code
> needs to be converted, then how can it still really be considered to be
> the same language?
Actually, there is hardly ever any _need_ to convert, because f77 is a
near-perfect subset of f90. Almost all f77 codes will compile unmodified,
and execute with approximately the same performance (sometimes a little
better, sometimes a little worse) using an f90 compiler.
Talk of "converting" to f90 generally means that people think that f90 is
so superior to f77 that it is worth re-writing their existing code to use
some of its new features.
One advantage of f90-style coding that is rarely talked about is the
performance advantage on the latest hardware. Eliminating dependence on
sequence and storage association greatly improves compilers' ability to
perform data placement optimizations on non-uniform memory access (NUMA)
configurations such as clusters and SMP-NUMA machines. These
configurations are already the top-performing Unix configurations, a trend
which will no doubt accelerate over the next year.
As compilers are optimized for these configurations, f90-style Fortran
codes will tend to out-perform f77-style codes.
-Israel Gale
ga...@hpc.pko.dec.com
Walt Brainerd
Sorry, I'm a bit behind on my reading, but this time Giles'
comments are just plain wrong. Already in the 1970s Fortran
vendors had stopped being very innovative (I'm not arguing
whether this was good or bad). In fact the IF construct
proposal was almost defeated because it was argued that
major vendors did not provide it in compilers (those who
wrote preprocessors did). There was no "existing practice"
for the character data type, another of the most popular features
of Fortran 77.
For Fortran 90, there is absolutely no evidence that I know of
that any vendors were even *thinking* of implementing things like
modules or derived types (structures, yes).
James Giles <james...@worldnet.att.net> wrote:
| Walt Brainerd <wa...@swcp.com> wrote in article
<5vma1k$i...@kitsune.swcp.com>...
| > If X3J3 had chosen this route, there would be no Fortran 90 as we
| > know it. There simply was no "widespread existing practice" for
| > such things as modules, dynamic objects, array processing (there
| > was some "<narrow>spread existing practice"), optional and keyword
| > arguments, argument intent, and most of the other important features
| > of Fortran 90. We would have had F77 + namelist + implicit none
| > and maybe a couple of other minor things and Fortran really would
| > be dead now, I think.
|
| This assumes that users and vendors would have been idle if there
| had *not* been a standard in the offing. I believe that to be unrealistic.
|
| . . .
|
| Fortran developed faster, and with better features, when
| vendors and the users community were more adventurous.
This may or may not be, but vendors have *not* been adventurous
for several decades.
Back to items of opinion: I happen to think that a committee often
designs things much better than an indiviual vendor. An excellent
example is NAMELIST I/O versus the very nice "name-directed"
facility that the standards committee developed and which was
voted down in favor of "existing practice".
A nice article relevant to all this was written by Jerry Wagener,
(Chair, J3), for the latest issue of the Fortran Forum.
William Clodius
Walt Brainerd wrote:
> <snip>
>
> This may or may not be, but vendors have *not* been adventurous
> for several decades.
I suspect that the very existence of a standard makes vendors and users
wary of new "extensions" to the language. Too many vendors and users
have found when an extension is added to an implementation it cannot be
removed or extensively modified, regardless as to whether the extension
was a good idea, the inertia of code relying on the extension is a
horrible stumbling block. Also the easy to implement extensions were
added first so that the incrementatal costs were increasing.
This is worsened by the non-orthogonality of the languages which means
that it is rare that an addition can be considered independent of the
rest of the language.
Note that for other languages, e.g., Pascal and PL/I, the most
innovative vendors have also been the largest vendors, and these vendors
have not implemented versions conforming with the standard, with the
result that portability between the largest vendor and standard
conforming implementations has been difficult in the extreme.
>
> Back to items of opinion: I happen to think that a committee often
> designs things much better than an indiviual vendor. An excellent
> example is NAMELIST I/O versus the very nice "name-directed"
> facility that the standards committee developed and which was
> voted down in favor of "existing practice".
This example is a two edged sword as the committee decided that existing
practice was better then the design of the subcommittee.
This debate has tended to focus on two options, innovations by
individual vendors vs. innovations by a committee. There are of couse
other sources of innovations
1. Academic implementations (this has has some effect on HPF). This is,
however, easier for smaller languages.
2. Design by a team with an explicit team leader. (Many languages
followed this route in the prestandardization phase. As part of its
standardization process, Ada has followed this route (relying on the
standards committee for consultation and yes/no approval but not on
detailed design), which has perhaps been made easier by the existence of
government funding for the team.)
3. Design by individuals or small groups (Many languages followed this
method in the pre-standardization phase.)
>
> A nice article relevant to all this was written by Jerry Wagener,
> (Chair, J3), for the latest issue of the Fortran Forum.
> <snip>
As always I recommend the articles of the late Brian Meek
http://www.kcl.ac.uk/kis/support/cc/staff/brian/brian.html
and the special issue on language standardization, Computer Standards
and Interfaces Vol 16 Nos 5/6, September 1994. A recent issue on Fortran
90 standardization might also be of interest.
--
William B. Clodius Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2 FAX: (505)-667-3815
PO Box 1663, MS-C323 Group office: (505)-667-5776
Los Alamos, NM 87545 Email: wclo...@lanl.gov
William Clodius
James Giles wrote:
> <snip>
>
> Yes, I've long been of the opinion that committees cannot do good
> to committees has long fallen by the wayside though.
A few points:
1. I thought you were a fan of Haskell
2. I thought Haskell was designed by a committee, albeit a small one
with particularly congenial and knowledgeable members.
3. Is widespread practice defined to be restricted to implementations of
the thing to be standardized or does it extend to other related things?
I.e., exceptions have widespread practice in the programming language
community, but not in the Fortran specific communities, similarly for
functional programming, object oriented programming, etc.
James Giles
William Clodius <wclo...@lanl.gov> wrote in article
<342AC1...@lanl.gov>...
> James Giles wrote:
> > <snip>
> >
> > Yes, I've long been of the opinion that committees cannot do good
> > (or even reasonable) language design work and should be restricted
> > to codifying widespread existing practice. That kind of restriction
> > to committees has long fallen by the wayside though.
> > <snip>
>
> A few points:
>
> 1. I thought you were a fan of Haskell
Yep.
> 2. I thought Haskell was designed by a committee, albeit a small one
> with particularly congenial and knowledgeable members.
Maybe I need to define "committee' better. A *small* group of
like-minded developers is more like a *faction* on a real committee.
Further, the Haskell committee is not affiliated with any national
standards organization, so no implementor needs fear legal
reprisals if they implement their own extensions and features
(as you *can* in some countries when you fail to comply with
a legal standard). As a result, the Haskell committee's activities
don't stifle innovation.
Still, Haskell is not growing in popularity with particular rapidity. So
maybe my original statement should be left to stand: the languages
which grow fastest in capability and popularity are those which have
no standard committee at all.
> 3. Is widespread practice defined to be restricted to implementations of
> the thing to be standardized or does it extend to other related things?
> I.e., exceptions have widespread practice in the programming language
> community, but not in the Fortran specific communities, similarly for
> functional programming, object oriented programming, etc.
If the Fortran committee were *ever* to adopt a feature which has
proved itself of value in another language, I'd have some basis on
which to gauge this practice. They tend not to. Instead, they add
features which are *called* the same thing as a similar feature
in other languages but which have significant untested distinct
qualities of their own. POINTER comes to mind in this regard, as
well as PURE functions. I've no doubt that any Object-Oriented
feature, exception handling feature, or idea borrowed from functional
languages would be completely distinct from such features used
in other languages (this could be good or bad - we certainly don't
want OOP if it's like C++ OOP). One problem would be that the
novel aspects of the feature would be untested in any really
large programming community - how do you know they're
good ideas?
Phillip Helbig
> I think it's dead. There's something with the Fortran name now, but it's
> not the same. Look at how many posts there are on the topic of converting
> F77 to F90.
Many of these are of the `upgrade VMS to OpenVMS' variety; that is, the
poster doesn't realise that Fortran77 is a subset of Fortran90 and thus
that a conversion is not necessary. Some other posts in this category
are concerned with converting nonstandard Fortran77 to (standard)
Fortran90. Unless a language is literally frozen (which would be death
in some sense, although it might still be used and supported), there is
always room for improvement, which means rewriting old code in a better
form. But one is not FORCED to rewrite old code.
> I think they outnumber the Fortran-to-C questions.
Well, this is a FORTRAN newsgroup :)
> If code
> needs to be converted, then how can it still really be considered to be
> the same language?
Again, a misunderstanding, I believe. If `need' means `the compiler
requires it' then no, if `need' means `it would be a good idea' then
maybe yes, depending on the application.
> I'll keep using Fortran, in F77 mode. But I've decided to not learn the
> new F90 stuff.
I am stricken with grief. It is definitely worth learning about array
processing, modules, derived types, new standard functions etc.
> Instead, I'm going to see if I'm not too old to learn C++.
And forsake the numerical advantages of Fortran (better optimisation
possibilities etc)? Fortran90 is also even easier to read and
understand than Fortran77, all else being equal.
> If I'm going to have to learn that much stuff, it might as well be in the
> form that the majority uses.
The Fortran90 user community isn't that small.
--
Phillip Helbig Email ... hel...@multivac.jb.man.ac.uk
Nuffield Radio Astronomy Laboratories Tel. ..... +44 1477 571 321 (ext. 297)
Jodrell Bank Fax ................. +44 1477 571 618
Macclesfield Telex ................. 36149 JODREL G
UK-Cheshire SK11 9DL Web .... http://www.jb.man.ac.uk/~pjh/
My opinions are not necessarily those of NRAL or the University of Manchester.
Jim Riley
In article <342AC1...@lanl.gov> William Clodius wrote:
>James Giles wrote:
>> <snip>
>>
>> Yes, I've long been of the opinion that committees cannot do good
>> (or even reasonable) language design work and should be restricted
>> to codifying widespread existing practice. That kind of restriction
>> to committees has long fallen by the wayside though.
>> <snip>
What do you see as the purpose of a programming language? Could a
design be considered good (or even reasonable) if what it produces is
merely useful?
--
Jim Riley
Craig Burley
jim...@pipeline.com (Jim Riley) writes:
IMO, the purpose of a programming language is to provide a means
for the author of a program to express how a computer is to carry out
its activities in a manner that is unlikely to be misunderstood
by a reader of that program (whether the reader is a human or
another computer program).
No, a "useful" result does not imply a good design. C++ is useful to
many people. It is a horrible language, but a pretty decent tool.
By comparison, MIT TECO was a poor language, but a great tool, for its
day; and FORTRAN 77 is a decent language, but has some shortcomings
as a tool, that latter which Fortran 90 improves upon, somewhat at the
expense of the former.
To get an idea of what it means for a language to be successful, consider
to what degree it is possible to *misunderstand* what the following
code means in Fortran vs. its counterparts in C and C++:
A = B + C ! Fortran
a = b + c; /* C */
a = b + c; // C++
If you think the above lines of code mean "add B and C, and store the
result in A", you're right -- except for C++, where it does *not* mean
that, but often *implements* that. (Even for C, one must assume the
preprocessor hasn't been abused; but one does not need to abuse C++'s
language facilities, in fact one can simply take advantage of widely
available libraries, such as those that provide a string data type
and overload `+' to implement concatenation, to make the "natural"
interpretation of the C++ statement incorrect.)
An example of a step backwards in Fortran 90 is this code snippet,
which can be easily misunderstood by an experienced reader of Fortran:
PROGRAM FOO
PRINT *, ABS(-1.4)
...
In FORTRAN 77, the above is properly understood to mean "print the
absolute value of the single-precision floating-point number -1.4".
In Fortran 90, it might not mean that at all, as illustrated by
appending the following text to the above program, perhaps thousands
of lines later:
CONTAINS
CHARACTER*30 FUNCTION ABS(D)
DOUBLE PRECISION D
WRITE (UNIT=ABS,FMT='(''Hey! '',G20.10)') D - 2.5D0
END FUNCTION ABS
Not only does this snippet completely change the meaning of ABS()
in the original code -- something that, in FORTRAN 77, can be
accomplished only by providing some kind of explicit statement
regarding ABS *above* its first invocation -- but it also changes
the type of the argument, which many compilers will support as
if the argument was -1.4D0.
This illustrates another important tenet to good language design,
which is that it should be easy to safely transform code snippets
using one set of language constructs to another set that is
considered (and documented as) similar.
For example, C supports `if...[then]...else...' as well as
`switch'. It is fairly straightforward to translate code using
one form to another, because there are few "magic" additional
meanings to either form, aside from the now-pretty-well-known
linguistic failing that requires inserting `break;' to get the
expected behavior.
FORTRAN 77 violates this principle somewhat, usually by disallowing
it. For example, you can't just take an external procedure used by
only one other procedure and "internalize" it as a statement
function, unless it is primitive enough (e.g. consists of only
one assignment statement, or can be made to do so).
Fortran 90 loosens up the situation, but makes it worse in
some ways by adding too many "magic" meanings.
For example, some people on c.l.f have reported problems resulting
from straightforward translation of code like
INTEGER FUNCTION X
INTEGER Y
...
... = Y(...)
...
END
INTEGER FUNCTION Y
...
END
SUBROUTINE Z
INTEGER X, Y
...
... = X(...)
...
... = Y(...)
...
END
to
SUBROUTINE Z
...
... = X(...)
...
... = Y(...)
...
CONTAINS
INTEGER FUNCTION X
INTEGER Y
...
... = Y(...)
...
END
INTEGER FUNCTION Y
...
END
In the first version, X's "INTEGER Y" is understood, in context, to
mean "the type of my sibling function Y is INTEGER", but in the
second version, the *identical* text ends up referring still to an
*external*, not sibling-level, Y, so the X function in the second
version does *not* invoke the Y function listed -- in fact, if some
*other* external procedure named Y has been added to the program,
it'll probably be silently, and incorrectly, invoked at run time by X.
This is due to host association rules and other what-not.
So, when converting from one reasonable form to another, the
Fortran 90 programmer must watch out for pitfalls like this.
Many vendors also "extend" their compilers by providing something
known as "widest-need evaluation". This, too, violates the
principle of straightforward replacement, with the main added
advantage being that programmers need not write what they mean
(that is, they don't have to append "D0" to their constants).
To wit, consider:
IMPLICIT DOUBLE PRECISION(A-Z)
R = 1.3 * 2D0
PRINT *, R
END
Compilers using widest-need evaluation will translate the "1.3"
as if it had read "1.3D0" (something the programmer could have
easily specified if he had meant that), leading to a *different*
result (printed) in R than if "1.3" had been translated to
single precision, as expected by readers of the Fortran standard(s)
(and as implemented by some compilers, including g77).
First, one *should* be able to generally replace variables given
a single constant value with constants, and vice versa, but
widest-need evaluation frustrates that. Compare the above to this
program, which *should* mean the same thing (and hence print the
same result):
IMPLICIT DOUBLE PRECISION(A-Z)
REAL S
S = 1.3
R = S * 2D0
PRINT *, R
END
Most, probably all, compilers will translate "1.3" to single precision
in storing it in S, which means the value that gets multiplied by two
will be different than the previous version. Yet, *most* people looking
at the above two snippets of code (and having read the Fortran standards,
without knowing the intricacies of widest-need evaluation) will
*misunderstand* the former version, assuming it means the same thing
as the latter, when it does not.
Now consider another kind of replacement, one where an expression that
might be frequently used is replaced by an internal function (in FORTRAN
77, a statement function):
IMPLICIT DOUBLE PRECISION(A-Z)
REAL V
S(V) = V * 2D0
R = S(1.3)
PRINT *, R
END
Some compilers using widest-need evaluation will produce the same
result as the first example above; others will produce the same
result as the latter. It depends on whether they treat statement
functions as being "carries of type" in determining the widest type
needed for the expression.
Even assuming *all* widest-need-evaluating compilers got the above
"right", that is, interpreted "1.3" as "1.3D0" above, now consider
what happens when *another* reasonable rewrite is performed on the
latest example above:
IMPLICIT DOUBLE PRECISION(A-Z)
R = S(1.3)
PRINT *, R
END
DOUBLE PRECISION FUNCTION S(V)
REAL V
S = V * 2D0
END
I'd guess that *no* compiler translated "1.3" as if it read
"1.3D0" and, continuing that approach, made V a DOUBLE PRECISION
variable. Or, if it did, it did it only when the two program units
are in the same file (or maybe only when S precedes the main program
unit), but not when in different files, *another* reasonable rewrite
a programmer could perform.
The result is that a straightforward replacement of one linguistic
mechanism with another, basically equivalent, one, introduces
*computational differences* resulting from a *different* meaning
that has been imposed on the replaced version, either because the
new linguistic mechanism has hidden "magic" meanings, or the old
one did, but basically because their "magic" meanings aren't in
agreement.
(In this case, the "magic" meanings of things like statement functions
and expressions include "silently promote all constants involved
with me and/or my dummy arguments in expressions to the widest
precision used", a meaning that is *not* part of an external
procedure, as illustrated above.)
This is an important, but oft-overlooked, reason people involved in
language design often refer to "orthagonality" as being important.
And Fortran compilers with the widest-need-evaluation extension
further reduce Fortran's already poor orthagonality, with little
practical advantage to show for it (and IMO, the advantages are
outweighted by the costs).
--
James Giles
Malcolm Cohen <mal...@sedi8.nag.co.uk> wrote in article
<60qk1k$kh2$1...@red.nag.co.uk>...
> In article <01bccaa5$009dfde0$947793cf@default>,
> James Giles <james...@worldnet.att.net> wrote:
> >Further, the Haskell committee is not affiliated with any national
> >standards organization, so no implementor needs fear legal
> >reprisals if they implement their own extensions and features
>
> A red herring - I know of no Fortran 90 compiler that does not implement
> *some* extensions.
Actually, F90 compilers tend to be very conservative. There seems to
be a widespread fetish of being exactly standard conforming (or even
sometimes reversing and making a subset compiler). Extensions, if
they exist at all, tend to be legacy extensions: the vendor supported
extended features in pre-F90 compiler and still supports those old
extensions. There seems to be no tendency to push for new features
at all.
> The control structure additions in F90 were all very closely modelled on
> features from other languages, as were derived types.
> [...]
> For scalars, "POINTER" is actually much the same as Simula 67 "REF" types,
but
> array pointers are pretty novel. Still, they are better than IDENTIFY/RANGE!
Very good. Making my point for me. The best of the features that are
*new* to F90 are those that had widespread existing practice behind them.
Indeed, the extent that POINTERs *are* similar to Simula 67 REF types
is pretty much the extent to which the feature has any positive design quality.
Pointers *shouldn't* have had any overlap or commonality with IDENTIFY/RANGE.
Ken Kennedy proposed a better solution for *those* in 1982.
> PURE functions were imported wholesale from HPF - that *is* just
standardising
> existing practice!
Well, how "widespread" a rarely implemented experimental extension can be
considered is in doubt. The only really poor design decision for PURE
functions
is the extent to which they differ from the concept of PURE that is common
to genuinely widespread languages. Namely, the value of F95/HPF "PURE"
functions are not independent of the execution history of the rest of the
program!
Ian Chivers
In article <3430E4...@smc.univie.ac.at>, Swietanowski Artur <swieta...@smc.univie.ac.at> writes:
>> >features which are *called* the same thing as a similar feature
>> >in other languages but which have significant untested distinct
>> >qualities of their own. POINTER comes to mind in this regard, as
>>
>> array pointers are pretty novel. Still, they are better than IDENTIFY/RANGE!
>
> some similar pointers in a more widely used language... With all the
> efforts aimed at consistency, safety and performance, F90 pointers are
> *very* badly designed and unsafe with too many exceptions to remember
> when one actually wishes to use them.
>
i am not sure what you mean here. the following c++ program passes
a 2 d array as an argument. this has to be done with pointers in
c++ due to the syntax of the language.
=============================================
#include <iostream.h>
void readdata(int* a,int n,int m);
int sum(int* a,int n,int m);
void printdata(int* a,int n,int m);
void readdata(int* a,int n,int m)
{
for (int i=0;i<n;++i)
for (int j=0;j<m;++j)
cin >> *(a+m*i+j);
return;
}
int sum(int* a,int n,int m)
{
int s=0;
for (int i=0;i<n;++i)
for (int j=0;j<m;++j)
s+=*(a+m*i+j);
return(s);
}
void printdata(int* a,int n,int m)
{
for (int i=0;i<n;++i)
for (int j=0;j<m;++j)
cout << *(a+m*i+j) << " ";
cout << endl;
return;
}
int main()
{
int n;
int m;
cout << " R and C ";
cin >> n >> m;
cout << endl;
int* a_ptr = new int [n*m] ;
int s=0;
readdata(a_ptr,n,m);
s=sum(a_ptr,n,m);
printdata(a_ptr,n,m);
cout << " sum is " << s << endl;
return(0);
}
======================================================
you may feel very strongly about pointers in fortran 90
but the above can be done very cleanly and easily in
f90 without using pointers at all.
the syntax of the inner loop with
*(a+m*i+j)
certainly isn't obvious.
ian chivers
king's college london
> Thus, I agree totally with the statement at the top and particularly
> with giving pointers as a vivid example of (supposedly) good intentions
> producing near-disastous results.
>
>> >well as PURE functions. I've no doubt that any Object-Oriented
>>
>> PURE functions were imported wholesale from HPF - that *is* just standardising
>> existing practice!
>
> Hmm, since when is HPF an existing practice? Can you name at least one
> full implementation of HPF 1.0 (and I don't mean the subset)? I believe
> one might exist, but I didn't find it yet.
>
> Artur Swietanowski
>
> ----------------------------------------------------------------------
> Artur Swietanowski mailto:swieta...@smc.univie.ac.at
> Institut fuer Statistik, Operations Research und Computerverfahren,
> Universitaet Wien, Universitaetsstr. 5, A-1010 Wien, Austria
> tel. +43 (1) 407 63 55 - 120 fax +43 (1) 406 41 59
> ----------------------------------------------------------------------
Malcolm Cohen
>In article <3430E4...@smc.univie.ac.at>, Swietanowski Artur <swieta...@smc.univie.ac.at> writes:
> If you could, please, give some comparisons between the F90 pointers and
> some similar pointers in a more widely used language... With all the
> efforts aimed at consistency, safety and performance, F90 pointers are
> *very* badly designed and unsafe with too many exceptions to remember
> when one actually wishes to use them.
Too many exceptions? I think not.
The rule is simple, for pointer operations F90 accesses the pointer, for
non-pointer operations F90 accesses the target.
The pointer operations are:
(1) pointer assignment
(2) allocate
(3) deallocate
(4) passing to a pointer dummy argument
i.e. F90 chose to delineate whether the pointer or target is referenced based
on the operation, not (as in Pascal and C) by annotating the operand.
>> >well as PURE functions. I've no doubt that any Object-Oriented
>>
>> PURE functions were imported wholesale from HPF - that *is* just standardising
>> existing practice!
>>
> Hmm, since when is HPF an existing practice? Can you name at least one
> full implementation of HPF 1.0 (and I don't mean the subset)? I believe
> one might exist, but I didn't find it yet.
There are several subset HPF compilers which include PURE, these have been
around for some time (so that at least is existing practice).
But to answer your question: NAGWare f90 at least has supported the full
HPF 1.0 language since early 1996. (It might not be an "interesting"
implementation of HPF to most users, since it does no parallelisation at all,
but it allows them to run their HPF codes on a single-processor workstation).
Malcolm Cohen
In article <01bccaa5$009dfde0$947793cf@default>,
James Giles <james...@worldnet.att.net> wrote:
>Further, the Haskell committee is not affiliated with any national
>standards organization, so no implementor needs fear legal
>reprisals if they implement their own extensions and features
A red herring - I know of no Fortran 90 compiler that does not implement
*some* extensions.
>If the Fortran committee were *ever* to adopt a feature which has
>proved itself of value in another language, I'd have some basis on
>which to gauge this practice. They tend not to. Instead, they add
The control structure additions in F90 were all very closely modelled on
features from other languages, as were derived types.
>features which are *called* the same thing as a similar feature
>in other languages but which have significant untested distinct
>qualities of their own. POINTER comes to mind in this regard, as
For scalars, "POINTER" is actually much the same as Simula 67 "REF" types, but
array pointers are pretty novel. Still, they are better than IDENTIFY/RANGE!
>well as PURE functions. I've no doubt that any Object-Oriented
PURE functions were imported wholesale from HPF - that *is* just standardising
existing practice!
>feature, exception handling feature, or idea borrowed from functional
>languages would be completely distinct from such features used
>in other languages (this could be good or bad - we certainly don't
Yes, there is almost always some need for a feature to be changed - whether to
avoid some deficiency in the original language's version or just to make it fit
in with other Fortran features.
Swietanowski Artur
> >features which are *called* the same thing as a similar feature
> >in other languages but which have significant untested distinct
> >qualities of their own. POINTER comes to mind in this regard, as
>
> For scalars, "POINTER" is actually much the same as Simula 67 "REF" types, but
> array pointers are pretty novel. Still, they are better than IDENTIFY/RANGE!
If you could, please, give some comparisons between the F90 pointers and
some similar pointers in a more widely used language... With all the
efforts aimed at consistency, safety and performance, F90 pointers are
*very* badly designed and unsafe with too many exceptions to remember
when one actually wishes to use them.
Thus, I agree totally with the statement at the top and particularly
with giving pointers as a vivid example of (supposedly) good intentions
producing near-disastous results.
> >well as PURE functions. I've no doubt that any Object-Oriented
>
> PURE functions were imported wholesale from HPF - that *is* just standardising
> existing practice!
Hmm, since when is HPF an existing practice? Can you name at least one
full implementation of HPF 1.0 (and I don't mean the subset)? I believe
one might exist, but I didn't find it yet.
Artur Swietanowski
Stuart Norris
Swietanowski Artur (swieta...@smc.univie.ac.at) expounded:
: > PURE functions were imported wholesale from HPF - that *is* just
: > standardising existing practice!
: Hmm, since when is HPF an existing practice? Can you name at least one
: full implementation of HPF 1.0 (and I don't mean the subset)? I believe
: one might exist, but I didn't find it yet.
GMD HPF (Adaptor)
DEC HPF
Portland Group HPF
--
Stuart Norris nor...@mech.eng.usyd.edu.au
Mechanical Engineering,University of Sydney,NSW 2006 wk:+(61 2) 9326-5276
http://www.maths.unsw.edu.au/~norris hm:+(61 2) 9351-2272
Swietanowski Artur
Stuart Norris wrote:
> Swietanowski Artur (swieta...@smc.univie.ac.at) expounded:
>
> : Hmm, since when is HPF an existing practice? Can you name at least one
> : full implementation of HPF 1.0 (and I don't mean the subset)? I believe
> : one might exist, but I didn't find it yet.
>
> GMD HPF (Adaptor)
Doesn't support pointers (F90) so it's not full HPF 1.0 (which as far as
I know should support *all* of F90). Doesn't support BLOCK CYCLIC
distributions (also part of HPF 1.0).
See the information page for ADAPTOR ver. 5 (the latest available)
<http://www.gmd.de/SCAI/lab/adaptor/language.html>
> DEC HPF
I have no access to it. The DEC web pages provide no specification, so
I couldn't verify. Lack of standards' conformance statement makes me
a bit suspicous. But an article on DEC's web pages at URL
<http://www.digital.com/info/hpc/fortran/loveman.txt> says that:
Digital's DEC Fortran 90 compiler is fully compliant with the Fortran
90 standard, supports nearly all(1) of the High Performance Fortran
Language Specification
> Portland Group HPF
This is the excerpt from their own manuals (available on the WEB at URL
<http://www.vcpc.univie.ac.at/services/software/pgi/ref_manual/>):
The pghpf compiler accepts the HPF language which is
a superset of Fortran 90. This version of pghpf
conforms to the High Performance Fortran Language
Specification Version 1.0, published by the Center for
Research on Parallel Computation, at Rice University
(with a few limitations and modifications, consult the
release notes for details).
Take a look at the last sentence, the part in the braces.
The previous version of PGHPF accepted about 20% of F90 and I didn't
bother checking what did the HPF part lack.
So I'd say that my remark was not that far off the mark.
Cheers,
Carlie Coats
Newsgroups: comp.lang.fortran
Subject: Re: Commentary on Language Inflation
Summary:
Expires:
References: <5uhbi6$9...@boofura.swcp.com> <3430E4...@smc.univie.ac.at> <60qvaj$e...@metro.usyd.edu.au> <34339F...@smc.univie.ac.at>
Sender:
Followup-To:
Distribution:
Organization: MCNC
Keywords:
Cc:
In article <34339F...@smc.univie.ac.at>,
Swietanowski Artur <swieta...@smc.univie.ac.at> wrote:
: Stuart Norris wrote:
: > Swietanowski Artur (swieta...@smc.univie.ac.at) expounded:
: >
: > : Hmm, since when is HPF an existing practice? Can you name at least one
: > : full implementation of HPF 1.0 (and I don't mean the subset)? I believe
: > : one might exist, but I didn't find it yet.
: >
: > GMD HPF (Adaptor)
:
: Doesn't support pointers (F90) so it's not full HPF 1.0 (which as far as
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Wrong. HPF 2.0 is based upon F90; previous versions of the
standard were based on F77.
: I know should support *all* of F90). Doesn't support BLOCK CYCLIC
: distributions (also part of HPF 1.0).
:
: See the information page for ADAPTOR ver. 5 (the latest available)
: <http://www.gmd.de/SCAI/lab/adaptor/language.html>
:
: > DEC HPF
:
: I have no access to it. The DEC web pages provide no specification, so
: I couldn't verify. Lack of standards' conformance statement makes me
: a bit suspicous. But an article on DEC's web pages at URL
: <http://www.digital.com/info/hpc/fortran/loveman.txt> says that:
: Digital's DEC Fortran 90 compiler is fully compliant with the Fortran
: 90 standard, supports nearly all(1) of the High Performance Fortran
: Language Specification
Supports all of HPF 1.1, almost all of HPF 2.0
:
: > Portland Group HPF
:
: This is the excerpt from their own manuals (available on the WEB at URL
: <http://www.vcpc.univie.ac.at/services/software/pgi/ref_manual/>):
must be an ancient edition. PGHPF 2.2 supports all of HPF 1.1,
most of HPF 2.0
Add IBM XLHPF which supports all of F90, all of HPF 1.1, and
most of HPF 2.0 (doesn't support arbitrary redistributions in
2.0). Has some implementation defaults that I strongly don't
like, but you can't say it doesn't fit the standard.
Stuart Norris
Swietanowski Artur (swieta...@smc.univie.ac.at) expounded:
: Stuart Norris wrote:
: > Swietanowski Artur (swieta...@smc.univie.ac.at) expounded:
: >
: > : Hmm, since when is HPF an existing practice? Can you name at least one
: > : full implementation of HPF 1.0 (and I don't mean the subset)? I believe
: > : one might exist, but I didn't find it yet.
: >
: > GMD HPF (Adaptor)
<summary --- boom! GMD HPF spirals into the deck and burns>
: > DEC HPF
<summary --- boom? DEC F90 flys through some flak and disappears
into a cloud. We are unable to ascertain if it took any
damage, but their propaganda doesn't boast about their
planes being bulletproof>
: > Portland Group HPF
<summary --- pop! PGHPF appears to be trailing some smoke>
: So I'd say that my remark was not that far off the mark.
Quite true. I stand corrected.
On the other hand, they all implement PURE functions, so you could
argue that the F95 standard is implementing an existing practice on
that issue.
You might be pleased to here that version 2.2 of the pghpf compiler
implements _most_ of f90 (rather than 20%) and seems a reasonably
usable HPF compiler. Omissions from F90 are
o Internal proceedures
o Recursion
and there are a number of restrictions on pointers, derived types,
modules, pure functions, and distributions of character and namelist
arrays.
The DEC compiler is much better. Omissions from HPF 1.0 in the DEC
v4.1 compiler are:
o WHERE statements inside FORALLs
o FORALLs inside WHEREs
o Nested FORALL statements
Actually their f95 compiler allows these statements, but their
parallelizing hpf compiler doesn't.
Cheers,
Swietanowski Artur
Carlie Coats wrote:
> : Doesn't support pointers (F90) so it's not full HPF 1.0
> Wrong. HPF 2.0 is based upon F90; previous versions of the
> standard were based on F77.
Look into the HPF 1.0 standard documents, please. Chapter 6, line 1:
"HPF is an extension of Fortran 90."
> : > DEC HPF
I looked at their web pages *at* *the* *moment* of writing the postings
(same for the other products). The information I give is the exact copy
of the information those vendors provide. Check out the web pages
yourself and don't tell me this must be an ancient edition. After all,
this is why I give the references to qouted sources.
> : > Portland Group HPF (PGHPF)
A statement from their web pages ***NOW***
PGHPF is currently implemented as a pre-processor to PGF77. Will
not be fully Fortran 90 compliant until a late 1997 maintenance
release (...)
Look at their ***RELEASE NOTES*** for PHGPF 2.2 sections 2.1 and 2.2
(Omissions and Restrictions, resp.). The URL is
<http://www.pgroup.com/ppro_docs/pghpf_rel/relnot.htm>.
> Add IBM XLHPF which supports all of F90, all of HPF 1.1, and
> most of HPF 2.0 (doesn't support arbitrary redistributions in
> 2.0). Has some implementation defaults that I strongly don't
> like, but you can't say it doesn't fit the standard.
I think this is another (4th) mistake in your posting. Read
<http://www.software.ibm.com/ad/fortran/xlhpf/justfact.htm> carefully.
You'll find:
IBM's XL High Performance Fortran for AIX (XL HPF for AIX) compiler
is an implementation ***based on*** the High Performance Language
Specification (Version 1.1, High Performance Fortran Forum,
November 10, 1994).
(stars above - mine)
and then
XL HPF for AIX, Version 1.2 also supports the following features
supported in XL HPF for AIX, Version 1.1:
o Subset HPF features with few exceptions
If you add this up, IBM claims to support SUBSET HPF 1.1, and even
that with exceptions.
Can you, please, check out what you claim before posting? I will not
look up any URL's for you again.
Henry Zongaro
In article <610phd$1...@robin.mcnc.org>, co...@robin.mcnc.org (Carlie Coats) writes:
|> In article <34339F...@smc.univie.ac.at>,
|> Swietanowski Artur <swieta...@smc.univie.ac.at> wrote:
|> : > Swietanowski Artur (swieta...@smc.univie.ac.at) expounded:
|> : >
|> : > : Hmm, since when is HPF an existing practice? Can you name at least one
|> : > : full implementation of HPF 1.0 (and I don't mean the subset)? I believe
|> : > : one might exist, but I didn't find it yet.
|> : >
[info. about various HPF compilers deleted]
|>
|> Add IBM XLHPF which supports all of F90, all of HPF 1.1, and
|> most of HPF 2.0 (doesn't support arbitrary redistributions in
|> 2.0). Has some implementation defaults that I strongly don't
|> like, but you can't say it doesn't fit the standard.
Unfortunately, you can. XL HPF supports all of F90 for serial Fortran,
but not in EXTRINSIC(HPF) scoping units (which is where it really matters).
We have most of the HPF 1.1 subset, but not all of it. We're missing
the following from the 1.1 subset:
o CYCLIC(n) distribution format
o ENTRY statements
o Some forms of internal I/O
As for full F90 support in HPF programs, in addition to ENTRY and full
support for internal I/O, we're also missing Fortran 90 pointers, and
we don't have support for non-constant DIM arguments of transformational
intrinsic functions.
I think that's the complete list.
Thanks,
Henry
-------------------------------------------------------------------------------
Henry Zongaro XL Fortran/XL HPF Compiler Development
IBM SWS Toronto Lab Tie Line 778-6044 Phone (416) 448-6044
Internet id: zon...@vnet.ibm.com
Swietanowski Artur
Henry Zongaro wrote:
> As for full F90 support in HPF programs, in addition to ENTRY and full
> support for internal I/O, we're also missing Fortran 90 pointers, and
> we don't have support for non-constant DIM arguments of
> transformational intrinsic functions.
The part about lack of support for F90 pointers in HPF worries me
a bit. One problem with F90 is lack of allocatable arrays in derived
types. You *have* to use pointers there, even if what you really
mean is an allocatable array.
It is often reasonanble to represent some object (e.g., a sparse
matrix) as a derived type object with a number of allocatable
arrays (represented by pointers for the reason given above).
As you can see, this is a very restricted use of pointers (i.e.,
you don't have to worry about them pointing to many different
things during their life; they point nowhere, or to just one array).
And I'd say it's quite useful and perhaps easier to implement than
the general mechanisms you'd need for pointer handling.
Regards,
Artur Swietanowski.