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