pklausler

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.

"The system worked yesterday, so it should have worked forever."

The second paragraph describes the motivation. I encourage you to read the paper.

This would also mean that we should design new programming languages out of sight of LLMs in case we need to hide code from them.

For a standardized language, Fortran isn’t very portable across compilers. GNU Fortran has done a great job supporting legacy features, and I hope that our work in flang-new has made it easy to port to, as well. I basically ignored the zealots who wanted flang-new to be a strict compiler by default. The hobbyist project LFortran is quite the opposite, and will yell at you by default for perfectly conforming variations in keyword spelling. For those who like that sort of thing, that’s exactly the sort of thing that they like.

Dummy arguments may not alias anything else, including other dummy arguments, in conforming Fortran if either are modified, with some exceptions. But there are many ways in which arrays can overlap that don’t involve dummy arguments. GNU Fortran optimizes ASSOCIATE names as if they were free of aliasing, too, but that is a bug.

fortran .GT. cobol

Your code will work unchanged until you try to change compilers or your compiler adopts a J3 breaking change to the language.

maybe they weren't really concerned about portability or a decent standard?

I wish that (still) worked reliably, but it can unfortunately get one into trouble with some compilers and some optimization modes that assume that NaNs are undefined behavior.

I'm curious, how old do you think I am?