Hi Alan,

On 2011-10-17 21:14, Alan W. Irwin wrote:
> @Arjen: There is a question for you at the end concerning
> deprecating/retiring our f77 bindings and examples.
> 
> 
> 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. :-)
> 

The only pure FORTRAN 77 compiler that might still be in wide use, as
far as I can tell, is g77. This compiler has not been maintained for
quite a few years now. gfortran supports most if not all popular
extensions to the FORTRAN 77 standards that g77 supports/supported.

If you want to test for strict FORTRAN 77 compliance, then g77 is
the only option.

However, many people still use that standard, that is, they do not
use the newer features. Since the FORTRAN 77 standard is an almost
strict subset of the Fortran 90/95/2003/2008 standards, those programs
continue to work. (There are some minor exceptions, such as the
use of REAL variables to control a do-loop, but compilers will likely
continue to support them for the coming years.)

That said, I think we could at least announce that we intend to
turn off the F77 bindings in the next release, with an indication
that the F95 bindings are the preferred set.

Regards,

Arjen
 

DISCLAIMER: This message is intended exclusively for the addressee(s) and may 
contain confidential and privileged information. If you are not the intended 
recipient please notify the sender immediately and destroy this message. 
Unauthorized use, disclosure or copying of this message is strictly prohibited.
The foundation 'Stichting Deltares', which has its seat at Delft, The 
Netherlands, Commercial Registration Number 41146461, is not liable in any way 
whatsoever for consequences and/or damages resulting from the improper, 
incomplete and untimely dispatch, receipt and/or content of this e-mail.





------------------------------------------------------------------------------
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

Reply via email to