Fortran 2000 Committee Draft
The formal position is that a CD (Committee Draft) Registration and Approval Ballot is in progress. The deadline for comments (from national bodies) is 27 December. Each national body will have its own deadline ahead of 27 December, so be sure to submit your personal comments to your national body well before then. For the USA, they should be sent to Deborah Donovan, email: ddonovan@itic.org. For the UK, they should be sent to David Muxworthy, email: d.muxworthy@ed.ac.uk.
John Reid, ISO/IEC JTC1/SC22/WG5 Convener
.................................................. ......................
ISO/IEC JTC1/SC22/WG5 N1494
Committee Draft revision of ISO/IEC 1539-1:1997 - Programming Language Fortran - Part 1: Base language
Abstract
Fortran is a computer language for scientific and technical programming that is tailored for efficient run-time execution on a wide variety of processors. It was first standardized in 1966 and the standard has since been revised three times (1978, 1991, 1997). The revision of 1991 was major and those of 1978 and 1997 were relatively minor. This proposed fourth revision is major and has been made following a meeting of ISO/IEC JTC1/SC22/WG5 in 1997 that considered all the requirements of users, as expressed through their national bodies.
The significant enhancements in the 1991 revision were dynamic storage, structures, derived types, pointers, type parameterization, modules, and array language. The main thrust of the 1997 revision was in connection with alignment with HPF (High Performance Fortran).
The major enhancements for this revision are
(1) Derived type enhancements: parameterized derived types, improved control of accessibility, improved structure constructors, and finalizers.
(2) Object oriented programming support: type extension and inheritance, polymorphism, dynamic type allocation, and type-bound procedures.
(3) Data manipulation enhancements: allocatable components, deferred type parameters, VOLATILE attribute, explicit type specification in array constructors, pointer enhancements, extended initialization expressions, and enhanced intrinsic procedures.
(4) Input/output enhancements: asynchronous transfer, stream access, user specified transfer operations for derived types, user specified control of rounding during format conversions, named constants for preconnected units, the flush statement, regularization of keywords, and access to error messages.
(5) Procedure pointers.
(6) Support for IEC 60559 (IEEE 754) exceptions.
(7) Interoperability with the C programming language.
(8) Support for international usage: access to ISO 10646 4-byte characters and choice of decimal or comma in numeric formatted input/output.
(9) Enhanced integration with the host operating system: access to command line arguments, environment variables, and processor error messages.
In addition, there are numerous minor enhancements.
Except in extremely minor ways, this revision is upwards compatible with the current standard, that is, a program that conforms to the present standard will conform to the revised standard.
The enhancements are in response to demands from users and will keep Fortran appropriate for the needs of present-day programmers without losing the vast investment in existing programs.
Just curious I guess.
healyourchurchwebsite.com - WWJB?
Yeah, trouble is a modern Fortran compiler is both hard to write and about as unsexy as it gets in the GNU/Linux world. Which is sad because the language is dismissed by folks who should know better, based on syntax that was obsolete even in F77.
Now we can return to the: I haven't used Fortran for 25 years, has anything changed posts? And why doesn't someone write an OO language based on C?
I hope this gets modded up as funny (because it is). However, I feel compelled to point out two things:
So Fortran may have taken us to the Moon, but it takes an expert system to slam probes into Mars.
How many /.-ers have ever written anything in Fortran? Sounds like a poll topic to me.....
Fortran isn't entirely dead. At least to the scientific community. I am a Fortran programmer, working at in a research position and I'm not 50 years old, I'm not even 20. (Yeah for co-op)
.Net. Try it some time, its a rather amusing little language.
Truthfully, anything that Fortran can do, C can do better. But that wasn't always the case. Fortran used to be A1 for number crunching, and thus is used and still used by many research companies. Sometimes, if you don't have a CS degree its just easier to use the language you learned when you were in University or College than spend the time learning C or Java.
Some older satellites (8-15yrs) used Fortran code. And if those satellites are still in the sky, (which they are) then those persons working on keeping and updating them need to use good 'ol Fortran to keep them up in the sky.
Each 'new' version of Fortran tries to get a little bit more object-oriented than the last. At the moment I use both 77 and 90 (neither are object oriented). Fortran also has the lovely feature of GO TO!
Fortran will probably be used for awhile longer. Even with
The original quote appeared in an issue of Scientific American that came out in the late 1990s. The article was on, you guessed it, the amazing longevity of FORTRAN. The bottom line is that there are a fantastic number of huge FORTRAN libraries out in the real world for doing all sorts of number crunching. The libraries are well understood, any bad behavior at boundary conditions is documented and they have a lot of milage on them so the results are generally regarded as valid. It makes far more sense to keep something called FORTRAN around that is compatible with this code than is does to attempt to re-write and re-test.
Oh, and no one cares that there isn't a pretty GUI interface to programs for analyzing structural stress, heat flow analysis, doing x-ray crystalography, etc.
They that can give up essential liberty to obtain a little temporary safety deserve neither safety nor liberty.
Ben
There are a lot of factories out running FORTRAN, usually on DEC/COMPAQ/HP OpenVMS systems to do plant floor control. I just ported an OpenVMS system to Windows 2000, about 1/3 of the code is FORTRAN. (Why not Linux you ask, because Linux does not have "events" like OpenVMS and Windows 2000 have. Given the extra time it would have taken to change the structure of the code, it was cheaper to buy Windows. Actually my customer would have prefered Linux.)
F77 was a cool language. IIRC, the original version of Adventure Cave used an interpreter that was written in F77. It is also one of the few languages that have native support for imaginary numbers (some versions of APL did as well).
Looking at the summary of changes, I suspect that they've finally messed up the things that made FORTRAN (or at least F77) great. The addition of pointers stands an excellent chance of rendering code un-optimizable, and I fear that adding OO features is an even bigger mistake. I would have liked to have seen Unicode support and exception handling, and that's about it.
Nothing for 6-digit uids?
I work in the flight sim business. I can assure you that every one of the 2 million plus lines of code written by my team over the last ten years was in C++ and for the ten years before that it was in C or Ada.
30 year old code will probably be in FORTRAN.
We do still have legacy code in Fortran. Mostly stuff we inherited from other simulators - and mostly in the area of simulating the actual flight dynamics. That stuff is hard to rewrite accurately and is a *tiny* fraction of a typical multi-million-lines-of-code simulator.
HOWEVER (dragging this screaming and kicking back on-topic) there is absolutely no need to invent FORTRAN 2000 just so we can run legacy code. If it's legacy code, that's because we can't/won't rewrite it - so why would we need a new revision of the language?
All that the world needs is a good way to call FORTRAN functions from within C++ - and we already have that.
FORTRAN should just be left to die peacefully.
www.sjbaker.org