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.

There are good reasons to use Fortran, some having to do with the language and many to do with legacy codes. These have to be balanced with the good reasons to avoid using Fortran for new development, which also have to do with the language and its compilers.

Honestly, if a language can't succeed in HPC alongside (or against) Fortran with its glacial rate of buggy evolution and poor track record of portability, and C++ with its never-ending attempts at parallelism, then it's not what HPC needs.

(What HPC does need, IMNSHO, is to disband or disregard WG5/J3, get people who know what they're doing to fix the features they've botched or neglected for thirty years, and then have new procurements include RFCs that demand the fixed portable Fortran from system integrators rather than the ISO "standard".)

I have worked on compilers (mostly) for high-performance computing for over 40 years, writing every part of a production compiler twice or more. Optimization and code generation and register allocation/scheduling are definitely the most fun -- but the hardest work is in parsing and semantics, where "hardest" means it takes the most work to get things right for the language and to deal with user errors in the most graceful and informative manner. This is especially true for badly specified legacy languages like Fortran.

CUDA Fortran was first released in 2007 and now has multiple implementations.

I don't think that BASIC was ever meant to be a better Fortran. Can you substantiate that claim?

I have a few patents, including one for a novel machine instruction, and I recall the attorney telling me that one cannot patent mathematics, only methods and systems.

I used a small custom parser combinator library to parse Fortran from raw characters (since tokenization is so context-dependent), and it's worked well.

Production compilers must have robust error recovery and great error messages, and those are pretty straightforward in recursive descent, even if ad hoc.

> First let’s accept the realities. The giant plagiarism machines have already stolen everything. Copyright is dead. Licenses are washed away in clean rooms. Mass surveillance and tracking are a feature, privacy is a bug. Everything is an “algorithm” optimised to exploit.

Suppose that I have discovered a novel algorithm that solves an important basic problem much more efficiently than current techniques do. How do I hide it from the web scrapers that will steal it if I put it on GitHub or elsewhere? Should I just write it up as a paper and be content with citations and minor glory? Or should I capture AI search results today for "write me code that does X", put my new code up under a restrictive license, capture search results a day later, demonstrate that an AI scraper has acquired the algorithm in violation of the license, and seek damages?

Is there a production compiler out there that doesn't use recursive descent, preferably constructed from combinators? Table-driven parsers seem now to be a "tell" of an old compiler or a hobby project.

The free market ensures that bridges stay up, because the bridge-makers don't want to get sued by people who have died in bridge collapses.

The logical combinators that I know all have definitions in the untyped lambda calculus. Is there a typed variant of logical combinators?

Enjoy!

If you like Leuchtterm, you'll love Quo Vadis Habana notebooks, if you can find them in stock.

We're definitely enforcing some of them. But the latest one from F'2023 isn't going to be.