Is GNU g77 Killing Fortran?

goombah99 asks: "I've come to believe that the existence of GNU g77 (and f2c) is holding back Fortran development. You might think that a free-ware compiler would be good for promoting the language. But it's not because the GNU flavor does not implement the de-facto standard DEC extensions to the language that give it dynamic memory allocation, pointers, and data structures. Without these Fortran 77 is indeed barbaric, but with them it is quite pleasant to work with. The problem is everyone writing new code is now afraid to use these commands in because of the desire to have their applications compilable by the teeming masses who may not want to pay $500 to $1000 dollars for a professional Fortran compiler (all of which do implement the DEC extension). F95 is being held back by the same considerations. Do you agree? Does anyone have some library extensions or pre-compilers that provide these capabilities to g77?" Are the DEC extensions so widespread and common that language survival is dependent on their inclusion, as the submitter suggests, in "every professional compiler". Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?

Comments

10 GOTO 20

[Dancin_Santa]

20 C++ faster than Fortran

Eventually? How about currently?

[devphil]

Assuming there aren't comparable features already available in g77, are there plans on eventually implementing similar?

There's already a team of very capable -- and young, not ancient/retired/whatever -- programmers implementing the Fortran 9x language, which defines some really interesting constructs. The current plan is for an initial release as part of 3.5.

Fortran 2000 has a spec, but I don't know of any implementations for it.

As far as "why is it still being used at all" comments, two words for you: no aliasing. The same reason why numerical computation in Fortran continues to chew C's head off.

It's "free software" not "free-ware".

[jbn-o]

You might think that a free-ware compiler would be good for promoting the language.

Haggle over the technical merit of g77 all you want, but free software is not the same as "free-ware".

Aliasing, Fortran, C, and C++

[devphil]

Yeah... I thought the CS community at large mostly knew about this. Okay:

Fortran specifies that Thou Shalt Not Alias, so in the example on the page that you linked to, the function-calling programmer, the function-implementing programmer, and the compiler can all assume that everything refers to non-overlapping memory, and can optimize the hell out of read/write memory accesses.

When Dennis Ritchie designed C, it was a deliberate decision to not prohibit aliasing. (C's ancestor languages may have allowed aliasing as well, and DMR just decided to continue that; I don't actually know. But the question was brought up and considered; it's not an accident.)

When C was first being standardized by ANSI, a really sloppy proposal was made to add a 'noalias' keyword. It was so bad that DMR sent a public letter to the ANSI committee stating, "noalias must go; this is non-negotiable." So C89 has no way of restricting aliasing.

C++98 and C99 do, sort of. C99 added the __restrict keyword to the language. C++98 left the core language alone and defined a library type, std::valarray, that is free of aliasing by definition, opening up a number of optimization possibilities.

Valarray didn't quite work out; its design is semi-broken. Far more hopeful is using expression templates to expose more of the numerical computations to the compiler, so that more optimizations can be done on visible numbers. Check out Blitz++ at oonumerics.org for an example.