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.
Just curious I guess.
healyourchurchwebsite.com - WWJB?
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
Isn't Fortran completely irrelevant in the 21st century anyways?
Absolutely not!!! NASA uses it to slam probes into Mars.
For those of us under 50, here's some history of the granddaddy of all high-level programming languages.
IIRC, my former graduate advisor and professor was on the team that wrote a very early Fortran compilers at MIT in the late 50s, written entirely on punch cards. We've come a long way in ~50 years.
:wq
I think in general it helps to teach more than one language. The current trend is to have a "core language" that schools teach in excruciating detail so that students will be able to go out and get a job right away, because they have a "skill".
But much of the time, they don't understand how or why what they've been taught actually works, which makes learning other programming languages vastly more difficult, since they're focusing on what's different in the syntax rather than on what's the same in the semantics.
</sarcasm>
T
---- It puts the lotion on its skin or else it gets the hose again. It does this whenever it's told.
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
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.
Back in my grad school days (5 yrs ago) everyone who had supercomputer time was writing in FORTRAN.
Amoungst physicists and astronomers, anyone with supercomputer time today is still writing in FORTRAN. I don't see that changing in the near future. Graduate students are starting to write in different languages, but to talk to their superivsors (the guys with large existing codebases) they have to be able to talk and write FORTRAN.
Most of the time its not worth their time to port a couple of hundred thousand lines of modelling code to some other language before they can add layers on top, its unlikely it'll ever be worth anyones time to do somethnig like that.
A lot of the Java, Perl/Tk and Python/Tkinter stuff I write these days is sitting ontop of a whole bunch of FORTRAN that it would take the next twenty years to rewrite. If it works, whats the point of doing it all again? Thats no fun...
I think language interoperability is becoming more and more important now the industry is (sort of) maturing. This is where code reuse in the real world is going to come from, rather than the current fads in code design which keep on promising more code reuse.
Al.The Daily ACK - Eclectic posts by yet another hacker
... is what FORTRAN is good for: number crunching. F77 is a perfect tool for many scientists who don't care about pointers or object oriented programming or nice graphical output subroutines or any other nice things that other programming languages have. They want something that will do some number crunching for them and won't screw up or cause problems.
FORTRAN is simple. It works like many mathematicians and scientists think it should. It meshes well with what they really want to do in a good number of cases. The level of abstraction is perfect for many of them.
FORTRAN will take a long time to die because of this. Personally, I like more real-time interpretive languages like IDL. But when it comes down to something that is pure number crunching that'll take a few hours, I'll gladly have FORTRAN. That's why so much in the sciences is written in FORTRAN, then the data is output and run through other programs to do the pretty plotting and further interpretation.
FORTRAN just works, has worked for 30+ years, and with the amount of incredibly useful code still around, will still work for decades to come. Granted, I don't necessarily like some of the proposed changes, but as long as everything works like it did before with F77 code, I think no one will (or should) mind.
-Jellisky