pklausler

But ‘95 is really the last standard to all be reliably portable across implementations. Features in later ISO standards aren’t always so.

Many “standard” features are not completely portable, since their specifications are ambiguous, incomplete, not validated by prototype implementations, and not enforced by public test suites. This makes Fortran compiler development hard; should each feature in a new compiler be compatible with existing compilers, or with the language in the ISO standard? And when the ISO committee changes semantics or breaks long-standing guarantees of the language like the integrity of parentheses, should a compiler break code?

It was good practice to draw a diagonal line across the top of a card deck with a magic marker, so that a dropped deck could be manually sorted easily.

Someday HN will go 24 hours without seeing this tired old quote, but today is not that day.

C# is the sharp note above C, enharmonic with D flat in a tempered tuning.

Fortran’s types have kinds, which are integer codes that further distinguish various flavors of each type. The ISO standard failed to define their meanings for the built-in types, but with any modern compiler worth using the kind values are the byte sizes. Literal constants can have a kind value as a suffix, and the suffix can be either an integer or a named constant. Fortran codes tend to establish named constants for the “working precision” kind and the next higher precision kind, so that one need only redefine those to compile various versions of a subroutine that work with different precisions.

Even when one isn’t defining named constants for various kinds, it’s still good practice to use them on literal floating constants, since those default to the default kind of REAL in Fortran, not to double precision as in most later languages. A very pernicious pitfall of the language is to (say) assign or initialize X=0.1 instead of X=0.1_8 when X is double precision.

People assume that DO CONCURRENT implies that a loop is parallelizable. But the committee botched the standard badly, and the language allows conforming code that is not parallelizable.

The standard language has had both dumb and smart pointers for 36 years. Based storage has been available as a common extension for over forty.

They ruled that the “integrity of parentheses” can be violated by fused multiply-adds, despite clear long-standing language to the contrary. So “(x * y)+z” can be compiled as if it were “x * y+z” and only undergo one rounding.

Sadly, Fortran’s guarantee of the “integrity of parentheses” has been undermined lately by its standard committee.

This point was weird, since Fortran has never had bitwise operators, as such. (It has had bitwise intrinsic functions since the “mil-spec” extensions in the late 70’s.)

Fortran seems to attract a lot of this sort of thing, perhaps because the language has had no real leadership since the ISO committee began jumping the shark in the 2000’s.

That is not a particularly well-informed discussion, unfortunately.

I think that the Voyager software is in assembly languages (there are several distinct computers on board), and that it is the program preparation software is written in a “Fortran V” extension.

I’m glad you like it.