Slashdot Mirror
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.
I had to learn F77 for a class my freshman year (1997, not THAT long ago) and we were working with F77. A part of that appeared to be because there were free compilers. Since most Fortran code is done in research groups that aren't computer groups, they may not all think to buy a real compiler.
A Free F2000 compiler - that researchers here about - would go a long way towards getting Fortran coders into Fortran 2000.
My understanding is that F95 and now F00 (or whatever) are "modern" langugages.
Amazing what you can do WITH backwards compatibility if you put energy into it.
Alex
I think that Fortran's move towards OO,
will not be of interest to most fortran coders
(who use fortran for the libraries, or who
cannot be bothered to learn another language).
It is interesting that C is not moving
in this direction, and instead the recent C99
revision addressed many the complaints of Fortran
coders (by introducing complex.h etc).
-j
Back in my grad school days (5 yrs ago) everyone who had supercomputer time was writing in FORTRAN. Just ask yourself, do you want to write a new optimized routine to compute the Cholesky decomposition of a positive definite matrix for a sparse matrix and store the resulting sparse matrix in band compressed form so that you can increase your grid size from 5k to 20k elements -OR- do you grab the linpack routines from http://www.netlib.org/linpack and go have a beer.
At the University of Minnesota beer usually won.
Truth: If it's not one thing, it's another
although for the size of our projects C++ is the obvious lnaguage of choice
Um... no. The language that your people are comfortable using is the language of choice. No other meaningful criteria exists.
Let's say there were some magic language, Foo, that was absolutely perfect for computational chemistry. It has standard library calls like solveThisHardProblemQuickly() and such. Just perfect.
Like any other programming language, Foo has a strict syntax. It's easy to write a buggy program in Foo, but tricky to write a perfect one. All languages are like this.
Your Fortran programmers decide they're going to abandon their preference and write in Foo instead. How many months do you think it would take for them to become conversant in Foo? How many trivial bugs will slip through in that time because your programmers weren't experienced enough with Foo to catch them? How far behind will you be at the end of the whole process?
And that's assuming that Foo is perfect. If Foo has its own idiosyncrasies and quirks, you can comfortable double those estimates.
There is only one inviolable law of computer programming: do what works.
...F77 is what you rely upon.
To calculate aircraft performance (i.e. can we take off with x passengers on this airfield that happens to have a big mountain at the end of the runway?) all (no exceptions) airlines use F77 calculation modules that are provided by the aircraft manufacturers.
These calculations are, at least in my book, as close to mission critical as you can come. Do it slightly wrong and you may end up in the safety net at the end of the runway. Do it majorly wrong and you hit the aforementioned mountain...
The modules are reasonably complex (up to 100k loc without a GUI), in strict F77 with the mess that that brings along and are written by Aerospace majors who, if they were lucky, got a 3 week course in F77 at University.
The obvious question is why?
- F77 is the most suitable language for the problem?
- Aerospace engineers like F77?
- It's an international conspiracy?
Unfortunately the last one is closest to the truth. The modules are coded according to a standard decided by IATA - International Air Transport Association (http://www.iata.org). A standard that was created some 20 years ago and with regards to F77 of course has not changed since... Why? Because the airlines knows how to handle these modules. The I/O and behaviour is well documented and understood and to change to something even resembling modern CS practices (even F90 would be a giant leap forwards!) would require huge investments for the airlines. Something they are of course not too willing to do. There are some reason for the currently ridiculously low (in comparison) fares we pay.
Oh, and by the way, the modules are of course not in any way certified by whatever competent authority there may exist. No, in general they prove their worth by the good old method of "service history".
PS. I have not given up flying just because I've experienced this. All aircraft operations have a rather large safety margin built in. For the "ouch" picture above with the very hard mountain top, we would also need to lose one engine. This in combination with the fact that the "service history" criteria seems to work pretty good still makes flying safer than walking...
No, what I don't understand about keeping fortran alive is because its users (scientists mostly) are people who refuse to use something new and better. They all use fortran 77 the way they learnt it through a 10 hour university course. I tried to get some of my users to use fortran 90 or 95 and failed pathetically. As my boss said: "if you think you have a clever programming trick, forget it !"
So what is the point of extending fortran with polymorphism and such ? They'll never use it. As a pro developper I'll never use it (I have the right tools already: C/C++/Java/assembler/perl depending on the job).
What is the point ? So they can sell expensive compilers with the new Fortran2000 sticker on it that nobody will ever use ? Marketting gimmick ?
Non-Linux Penguins ?
String handling in FORTRAN 66 was not very portable. On the DECsystem-10, five ASCII characters were stored per word. This was the biggest hassle in porting to another platform.