@Arjen: There is a question for you at the end concerning
deprecating/retiring our f77 bindings and examples.
On 2011-10-14 08:26+0100 Andrew Ross wrote:
[...]
>> FFLAGS is used for both f77 and f95 compiles which makes it hard to
>> tailor the flags for different standards. Again, it is a limitation
>> of cmakes handling of these things.
[...]
> FFLAGS=-O3 -fvisibility=hidden -pedantic -Wall -Wextra
[...]
> So far I've not even looked at [...] fortran. If someone with more fortran
> insight wants to take that on it would be good.
Hi Andrew:
In connection with a different project I have just looked at the -std
capability of gfortran, and it makes for interesting reading:
<quote from info gfortran>
`-std=STD'
Specify the standard to which the program is expected to conform,
which may be one of `f95', `f2003', `f2008', `gnu', or `legacy'.
The default value for STD is `gnu', which specifies a superset of
the Fortran 95 standard that includes all of the extensions
supported by GNU Fortran, although warnings will be given for
obsolete extensions not recommended for use in new code. The
`legacy' value is equivalent but without the warnings for obsolete
extensions, and may be useful for old non-standard programs. The
`f95', `f2003' and `f2008' values specify strict conformance to
the Fortran 95, Fortran 2003 and Fortran 2008 standards,
respectively; errors are given for all extensions beyond the
relevant language standard, and warnings are given for the Fortran
77 features that are permitted but obsolescent in later standards.
</quote>
So gfortran has no support for a strict Fortran 77 standard. That's
probably okay. My experience with strict Fortran 77 is it is a real
pain to use; historically there were a lot of extremely useful
extensions to that standard for VAX/VMS Fortran that became a
pseudo-standard themselves. It is that pseudo-standard that I have
tended to use over the years for the "Fortran 77+" scientific
libraries and applications that I have implemented so it is
likely that my contributions to our standard f77 examples includes
those language extensions.
So given the state of legacy fortran support in gfortran, here is what
I think you should do.
* Do your initial Fortran tests with f77 disabled. This should allow
you to use -std=f95 to weed out any problematic code in our f95 bindings
and examples.
* Finish by enabling f77 and using -std=legacy. This is a pretty
weak test since it does not discriminate in the slightest against pure
Fortran 95 code getting into our f77 bindings and examples, but I
think you should perform this test just in case it discovers some
"Fortran 77" code that is problematic in general.
* At some point I think we should deprecate and then retire the f77
bindings and examples. A lot of the scientific libraries and
applications I implemented over the years were written in "Fortran
77+", and my knowledge of modern Fortran is still pretty shaky.
Nevertheless, even I can see that the Fortran 9x and 20xx changes were
a long-overdue revolutionary change to Fortran 77 that has turned
Fortran into an extremely powerful and interesting language. So I am
not sure how much longer it would be worthwhile for us to put any
effort into our f77 bindings and examples when there is a lot of
interesting things we could be doing with our f95 bindings and
examples instead.
@Arjen: I would be extremely interested in your take on this matter
since you probably have the best knowlege here of the overall state of
Fortran. Also, since you are the guy that has been maintaining our f77
bindings and examples I think the decision about when to
deprecate/retire these bindings and examples is strictly your call.
Nevertheless, I do suggest you at least consider the matter in terms
of cost of maintaining those f77 bindings/examples versus the benefit
to our users. The key part of that analysis is your best guess at
whether there are still substantial numbers of Fortran users out there
who still prefer using our f77 rather than f95 bindings and examples.
My guess is there are not, but I trust your guess more than mine. :-)
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
