I’m excited to share FortranChess, a chess engine entirely written in modern Fortran. This project demonstrates Fortran’s capabilities beyond scientific computing, tackling a complex problem like chess with clean, efficient code.
While chess engines are often written in C/C++, this project explores Fortran’s strengths in structured programming and performance optimization—even for non-numerical tasks.
Do you use any of Fortran’s parallel features in this project?
no I do not
Welcome! This is great, I played a quick match and it was pretty good! Have you tried estimating it’s Elo at different depths? and how they compare to other engines?
And also do you plan on adding more features? I think adding primary support for Algebraic notation and also implementing UCI would be great additions to the project.
Maybe
With enough work, maybe it could be entered into some computer chess tournaments.
One of the Founding Fathers of scientific computing, John von Neumann stated " Chess is not a game. Chess is a well-defined form of computation" so its only natural that Chess and Fortran are a good match. The complete quote is here
The only built-in Fortran parallel feature is do concurrent. More generally, regular loops or array syntax statements can possibly be parallelized by an optimizing compiler. But I think that task based parallelism is better suited for this kind of algorithm that explores a tree. Fortran doesn’t have tasks yet, but OpenMP can be used for that.
There are also the coarray features.
…And asynchronous I/O.
Of course… Shame on me 
…
Emphasis mine, I’d love a native way to do asynchronous, parallel tasks. Something like that would be very useful for more computation-engine-type programs.
There has been some discussions at the commitee level, but it doesn’t seem to be part of F202Y.
https://j3-fortran.org/doc/year/23/23-246.txt
@PierU I thought this one (23-174.pdf) was the one under consideration, isn’t it?
The one you pointed to has the “pure procedures only” restriction, which limits its usefulness when compared to asynchronous implementations in other languages.
Maybe… But this one is from 2023 as well, and I can’t see any recent formal proposal (these one are labelled as “info”).
The one I mentioned is in this list of accepted items: https://j3-fortran.org/doc/year/24/24-167.txt
Hopefully they won’t drop it.
In addition to OpenMP, which was mentioned previously, one can also do asynchronous tasks using coarray features. Of course, in both cases, OpenMP and coarrays, the compiler plays an essential role. If you want to avoid that compiler participation requirement, then MPI is implemented just through library calls, and it can also do asynchronous task programming.
Array syntax is an expression of SIMD parallelism. It was based on extensions used in a number of Fortran compilers for various parallel and vector machines in the 1970s/1980s. On machines such as the Connection Machines and the CDC CYBER-205, array syntax almost directly translated into machine instructions.
(Though lowly BASIC had array syntax back in the 1960s.)
@dmenezes great job, and welcome to the forum!
I played a quick game: chess.txt · GitHub, it leaves pieces hanging, so I am guessing it is not searching many moves ahead yet.
You might consider implementing the UCI interface, so that you can use it with GUI chessboards.
Thanks, I haven’t written any Fortran, but I bought the book Modern Fortran: building efficient parallel applications.
I wrote a checkers/draughts playing program using C++ for an AI course in graduate school. I don’t think I tried parallelizing the search, but I tried to make it explore possible moves in the background while waiting for the user to make a move. I believe I used the pthreads library for that, but I’m pretty sure I could have done it with OpenMP.
OpenMP doesn’t seem to be used as much in C++ (I could be wrong), maybe because often the actions are conceptually tasks, but I think OpenMP would be able to handle a lot of that nicely with code that is higher-level and easier to read and program.
I wrote the program quickly because I was so busy in graduate school. I never worked out all of its bugs, and from time to time, I think about re-writing it, maybe not in C++ this time.
I played the exact same opening too and after exd5 the engine played Qe7+ which is fine, instead of Bb7+ (the move in your case) which is straight up losing for black… Did you change the depth level in the source code? Or any other possible reason?