We asked the same question when contemplating whether to switch fpm development to Fortran. It turns out it was a great decision. I’m not saying that means a Fortran compiler written in Fortran will necessarily turn out the same way, but it could.
Don’t take my suggestion to mean I’ve thought very long or hard about it, but I think the experience from fpm (the conventional wisdom would have been you’re crazy to try writing a package manger in Fortran) demonstrates that maybe the conventional wisdom isn’t still true that Fortran would not be well suited to writing a compiler.
Just to avoid misunderstandings: Mentioning that it took 20 years was not at all meant in a negative way. I rather wanted to express how much work and experience went into this projects.
It is the same for commercial compulers like the ones of Intel and NAG that have a even longer history.
That is exactly the point I was making. I also have several editions and printings of this book, and they are all different because the language changed over time in the 1980s and 1990s. And the language has changed even further after the last K&R printings up to the present.
I understood . My point still stands, whereby we shouldn’t get to a point where there is no one to carry the torch of those 20 years of hard labour, and lower the contribution barrier so that people’s work is preserved and lives on.
I just want to say I’m sympathetic to this argument. I don’t think it would be a good idea to start yet another Fortran compiler project if it came at the expense of any of the existing projects. But I don’t think it necessarily would.
My suggestion was primarily that, if there are Fortran developers out there that aren’t really proficient in C or C++ and don’t want to take the time to learn LLVM or GCC, that they shouldn’t feel discouraged from playing around with writing a Fortran compiler in Fortran.
Considering the following discussion I weaken my statement from “I don’t think that it is beneficial” to “I am not sure whether it is beneficial due to concerns about the number of available contributors for free Fortran compilers”.
Please see this thread. My request to the Fortran standard-bearers and the Community is the addition of just a handful of further features can make Fortran an extremely powerful language not only for the broader needs that have already arrived and are burgeoning in the scientific and technical computing domains but also it can enhance Fortran as a general-purpose programming language.
Indeed one can envision multiple benefits with bootstrapping compilers. The findings with fpm mentioned by @everythingfunctional are cool to read from the point-of-view of Fortran.
Now, it’s not that these few additional features as I suggest are an absolute must, but their inclusion in the language standard can make many aspects a lot more efficient and productive with Fortran and many a future application in scientific and technical computing space will also benefit as a result.
I’ve written a parser combinator library, parff, but I wasn’t super happy with it. It was slow and not as easy to use as I would have liked. It might be a reasonable starting point to design a better one though.
In theory, you can write any application or algorithm in any Turing-complete language. For example, you could implement an operating system using Morse code using a telegraph machine for input, by mapping long and short to 1 and 0.
In practice, programming languages are better at some domains than others. For example, Perl is great at some things and terrible at others. Fortran was designed for numeric computing, not string processing, although dozens of simulation code input parsers prove that it’s possible to write the latter in Fortran 77. Fortran lacks intrinsic support for common data structures that are likely to be useful to compiler writers, although C also lacks them, too (but its pointers are more flexible).
Anyways, I think there are far better uses of your time than writing a Fortran compiler in Fortran. Similarly, I’d discourage you from implementing a POSIX-compatible operating system in Fortran, unless your primary goal is to be an iconoclast, rather than successful.
Contribute to GCC or LLVM Fortran projects if you want to have an impact on the world. You’ll avoid reinventing a million wheels and be part of a community of people who can help you.
I gotta ask though, why do people prefer LLVM over GCC, or vice versa ?
When Chris Lattner was conceptualizing LLVM, why weren’t there people like you to shoo him away from being creative by saying "Yea, technically you can make a compiler backend out of a light switch, although only people without epilepsy can use it " ?
Obviously, Chris saw things lacking in GCC and went ahead with his idea.
In, the similar vein, gfortran development has slowed down due to the more experienced gfortran devs being kicked to the curb by the transition to git as steve earlier said. What this does, is reduce the pool of devs experienced in GCC.
The general idea of making a compiler in Fortran, is so that people won’t have to learn C or LLVM, since they already know Fortran (cause they’d be using it) and can contribute easier. Thereby increasing the people who can “help”.
But, I can see where you are coming from and have chosen to help ondrej with his lfortran compiler(LLVM based).
Also why do you recommend against a posix-compatible operating system in Fortran ?
“LLVM was originally developed as a research infrastructure to investigate dynamic compilation techniques for static and dynamic programming languages.”
Only after Apple hired Lattner and he started working on Clang did LLVM become a peer to GCC. An obvious reason for it to exist was licensing.
In any case, you ought to consider how survivorship bias colors this discussion. For every Lattner, there are hundreds of computer scientists who set out to create a new compiler and end up making no measurable impact on the world.
You’re free to ignore me. I’m just sharing what I’ve learned over the past 20 years. I’ve had far more impact on the HPC works building on established projects and ideas than creating new things.
Also, if you’re going to invent something new, it helps to understand the current state of the art. Work on an established project for a few years until you’ve figured out how compilers work, then go create your own.
I am not ignoring you, just furthering the discussion and trying to get you to expand on why you are against it. I am taking your words very seriously.
Is it accurate to say that gfortran is mostly in C’89/'90? I’ve been looking at the more recent C standards (C23 is now out) and members of the standards committee (ie. Robert Seacord) consider K&R “increasingly obsolete”. I consider this potentially important as the newer Fortran standards make reference to recent C documents.
I reread the last post by Karlgl and found his point about compiling with -std=c89. The broader point remains about compatibility with more recent versions of C, but it might not be a serious problem in practice due to the enormous amount of c89 out in the wild.
The problem due to a switch to git might be solved by this:
RE: a re-write of the Fortran front end in Fortran. That is theoretically elegant, but from a practical POV, any compiler implemented in C (or C++) will be easier to bootstrap and port to other systems. Users only care about the code generation, compile times, and error messages. Anyone who hacks on Gfortran or LFortran gets the advantage of putting C and/or C++ on the resume (which need to be known anyway) instead of just Fortran.
. My point still stands, whereby we shouldn’t get to a point where there is no one to carry the torch of those 20 years of hard labour, and lower the contribution barrier so that people’s work is preserved and lives on. 
I reread the last post by Karlgl and found his point about compiling with -std=c89. The broader point remains about compatibility with more recent versions of C, but it might not be a serious problem in practice due to the enormous amount of c89 out in the wild.