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.
If you wish to contribute a program then please follow these instructions:
The paragraph it's used in ("Why is PYPL so different from TIOBE ?") seems to argue that TIOBE is lacking, not lagging.
'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.'
Edit: Looks like OOP support arrived in Fortran 2003. Does anyone know how much of a difference it made?
In fact, during the 60's Algol variants were already being used to write compilers and OSes.
What does this mean, and how is this any different from e.g. C?
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).
A forth in forth that is a cross compiler or something, doesn't quite "feel" like a forth system?
See also: https://www.forth.com/starting-forth/11-forth-compiler-defin...
Ed: now I'm kinda excited about an llvm forth...
> 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!
GCC is similar.
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)
In three years when LLVM bumps to C++'17 or whatever, then flang starts obeying.
But also I personally think is fine for parts of the project not needed to build C++ to use newer C++. Just use the newly built clang to build flang!
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.