I write code in modern Fortran 2018, making extensive use of the new language features, so this is welcome news. I use Intel Fortran Compiler 2019 at work and gfortran-8 at home.
Modern Fortran looks completely different from the old school FORTRAN77 that most people envision when thinking of Fortran. For reference, I did this past year's Advent of Code contest all in Fortran[0].
I always feel that Fortran is under-represented on the benchmarks game, so let me take the opportunity to say fyi that we are usually happy to accept better programs.
If you wish to contribute a program then please follow these instructions:
This is awesome! Fortran is still in use in many of the "hard" sciences. It will probably take several years, but this may mean we could consider deprecating one of the compilers we have to maintain for people.
Fortran used to be more popular. However, TIOBE is a lacking indicator, as stated here: http://pypl.github.io/PYPL.html (do a in-page-search with "Why is PYPL so different from TIOBE ?") Some other indicators such as Redmonk ( https://redmonk.com/sogrady/2019/03/20/language-rankings-1-1... ) show that both Dart and Rust are more popular than Fortran. (Although each of them have their own set of biases.)
'The LLVM compiler infrastructure project is a "collection of modular and reusable compiler and toolchain technologies" used to develop compiler front ends and back ends.
LLVM is written in C++ and is designed for compile-time, link-time, run-time, and "idle-time" optimization of programs written in arbitrary programming languages.'[1]
If a Fortran compiler were self-hosting, I might think twice before using it... I can't imagine implementing a parser/lexer in Fortran of all languages. Considering that loops and procedures are the main supported models of indirection/abstraction, I expect the defect rate per kLoC would be rather high.
Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?
I'm sure they did. I'd even expect most compilers were written in a HLL. Note that most refers to quantity: I expect most compilers were written as an academic exercise with no real intent to be used in production. I would expect the compilers that were intended for people to use to write production code were written in assembler because at the time compiler optimizations where not very good; computers were slow and expensive; and programmers were cheap: as such it would be worth the extra cost to write your compiler in a low level language.
Fortran has evolved a lot. You can practically use any programming paradigm with it. If you chose well a subset of all its features, you can actually write quite elegant code. I have never used it for this and do not have any example, but I would not expect it to be particularly worse than any other language.
From the use-cases I've seen, OOP didn't make a massive difference. Many of the ideas from OOP were possible before, e.g. abstraction with modules and derived types (essentially C structs) from Fortran 90/95. Others, like polymorphism felt a bit bolted on and haven't gained widespread usage.
As for a self-hosting compiler, I'm not aware of one, although it's something I'd be interested in having a go at. I've written a regex engine in Fortran before, I just haven't had the time to sit down with the Fortran standard and a textbook on compiler design (I'm a physicist by trait, so I've not been taught this stuff formally).
I'm not sure that makes much sense;forth is typically a thin layer over a machine (historically physical, but also a VM, like the jvm) - so it'd generally make sense to implement the "compiler" is "assembler" (whatever that means for a given "machine")?
A forth in forth that is a cross compiler or something, doesn't quite "feel" like a forth system?
> The board also recommends that f18 evaluate (over time) whether it is reasonably possible to eliminate the dependence on C++’17 features.
Alright...
> Using C++’17 is not a blocker for inclusion into the project, but will be a blocker for certain other infrastructure (e.g. build bots and integration into official releases), but those may or may not be relevant now given the early state of f18.
C++'17 is too new for the developers of the premier C++ compiler to use in their CI? What is this hot garbage!
They should still be able to CI it on the min version that does work. Eventually c++'17 will be old enough, so definitely the thing to do is just wait.
LLVM supports old platforms: some CI bots are targeting stable Debian, or Ubuntu 14.04.
LLVM is currently moving to C++14, which is a pain for some users like TensorFlow for instance which supports Ubuntu 14.04: the c++ standard library is too old.
There are technical solutions for everything but for a component like LLVM, not pressuring its users into convoluted workflow is important.
Of course the LLVM developpers would love to just use the latest version of the standard all the time. For the library part of the standard, it is worked around by having its own: https://github.com/llvm/llvm-project/blob/master/llvm/includ... (and others in the same directory)
This is ignoring that LLVM is first and before all designed as reusable libraries.
Bumping requirements is causing other problems than just being able to build with the just built compiler: namely deployment and integration in other products. For example, you may be forced to isolate components in dynamic library that talks with each others through C APIs and each statically link the C++ standard library. It can become fairly complicated when this does not fit your setup and you get forced into this because LLVM decided to bump their standard.
Modern Fortran looks completely different from the old school FORTRAN77 that most people envision when thinking of Fortran. For reference, I did this past year's Advent of Code contest all in Fortran[0].
[0] https://gitlab.com/bwearley/advent-of-code-2018/tree/master