Fortfront transpiler from lazy to standard Fortran

1

Fortfront is an ambitious effort by Christopher Albert to translate concise pseudo-Fortran without declarations to standard Fortran with implicit none. The repo describes the dialect as “lazy”, but it does not have lazy evaluation. The code

isum = 0
do i=1,10
   isum = isum + i
end do
print*,isum

for example is translated to

program main
    implicit none
    integer :: isum
    integer :: i

    isum = 0
    do i = 1, 10
        isum = isum + i
    end do
    print *, isum
end program main

The author lists Claude (the LLM) as a contributor and uses it heavily. He has quickly fixed many issues I submitted. I encourage other members to try his project and give feedback. It would be ideal if you could program in a language as concise as Python and as fast as Fortran.

2 Likes
2

I forgot the link:

3

Personally, I would love a “FortLab”. Basically a MATLAB for Fortran code. Recently, I’ve translated some MATLAB/Octave code over to Fortran. Having the almost instantaneous results from the original code to compare against greatly shortened the porting effort. This raises a few questions that I would like to hear other folks opinions on.

  1. What are the current roadblocks to implementing an interactive environment for Fortran that matches MATLAB/Octave. I think the work that @certik is doing with LFortran could be a path to the interactive requirement but what other “enableing technologies” are needed. Do some (most) already exist?
  2. Is this something other people besides myself would want and use.
  3. I presume the level of effort to make this happen is beyond the ability of a single programmer (at least to deliver something in a reasonable time period). However, are there enough pieces in place (ie stdlib etc) to at least start a preliminary proof of concept.

I think if something like a “FortLab” existed, it would accelerate a move back to Fortran. If nothing else it would give Fortran a development environment for rapidly prototyping code.

Just curious what other people think

4

Another new project that I encourage people to test is

There is also

5

It’s very easy to get some small subset working interactively. But when using, very quickly you discover that you want to use existing Fortran code, so you need a Fortran compiler. It’s easy to write a Fortran compiler for a small subset. But you quickly discover that most projects always use some features that require all corner cases to get right. So overall it takes time. Once LFortran reaches beta quality meaning it can compile most codes, we want to get the interactive experience working well. Yes, I think it will be useful to have an “--infer” mode where it infers the types, and is able to either compile it or generate regular Fortran equivalent code.

6

Thanks. I think a good first step would be a minimal GUI that at least had the capability to first infer type and then (as the the FortFront example above) generate code with explicit typing (probably a menu or GUI button). Also with the ability to infer INTENT and then offer a user a way to change it.

1 Like
7

There were at least three interactive F77 interpreters and a number of Fortran-based embeddable and/or stand-alone scripting langages at one time but the only one I could find was DATATRAN. Some of the interpreters diverged significantly from Fortran to accommodate interactive usage so I was thinking their feature sets would be a good starting point, but so far have not found them. Not that you do not have to carry your codes in a box of cards it may seem surprising, but implicit typing was very handy. Command line recall ala “readline” type operations was in all of them I recollect; all has some basic plot capabilities at a minimum. throwing an error did not cause program terination, and NAMELIST-like groupings were useful to printing self-describing output of a number of variables with just a single argument. Lots of “standard” operations for printing subtables to file, writing CSV files to import into other programs, importing of CSV and NAMELIST file; linear algebra, basic statistics (DATATRAN of course has a huge number of statistical options) and sorting, and checkpointing and resuming and replayable journals and extensive built-in help were all part of the interaactive interfaces. I know there were other features or extensions that just seemed mandatory for interactive use, but it is hard to remember it all. I think some packages like a relational database called RIM0, extensive math libraries and other features were bundled up with ROOT and STAR but not sure. The NSC scripting language NCL was a very popular one were I as at at one time.

Although partly a homage and for program inspection and unit testing, the M_matrix fpm package mentioned above has a command editing mode similar to the CDC REDO command; a one-line interpreter that is literally based on the original MATLAB (which was written in Fortran), and command journaling that give a taste of what those packages were like. I think any new ones have to have those major features as well.

1 Like
8

How would it handle something like this? without specifying the types

program demo
    use shapes
    implicit none

    type(Circle) :: c
    type(Square) :: s

    call c%create(2.0)
    call s%create(3.0)

    print *, "Circle area:", c%get_area()
    print *, "Square area:", s%get_area()
end program demo
2 Likes
9

The old interpreters were F77 or F77-like. No user-defined types I remember. It would have been more like

side=3;dia=2
print "Circle area:",area_c(dia)
print "Square area",area_s(side)

where you have loaded function definitions “area_c” and “area_s”.

1 Like
10

Among the fortran-based scripting languages, I also recall fortran_script.

11

Author here, thanks for posting @Beliavsky ! The whole lazy-fortran · GitHub orga is a collection of heavily vibe-coded packages that should explore how to combine the best of the breed features of Python, Go, Julia and Rust for Fortran. It is completely experimental and can break any day currently! I started with GitHub - lazy-fortran/fortrun to run Fortran files like Python scripts with fpm cache in the background, and soon added basic type inference that was then extracted to fortfront. This is more than just a preprocessor, I am actually learning how to build a compiler frontend with it. @certik I am a big fan of LFortran and share the vision on making Fortran the universal language it had the potential to be! I would be curious what’s your take on claude code & co. I had quite some sucess with porting matplotlib to fortplot, but with AST logics its getting much harder and slower.

1 Like
12

Excellent!

Claude code is awesome (so is VSCode Copilot, very similar), I started using both recently. I still have to do the design and hammer down the complexity that claude code creates if left unchecked. But I found the skill to do that to be almost the same as managing a team of people, e.g., for LFortran. All my time is occupied with improving the design, and reducing complexity and removing technical debt.

I have dozens of unfinished small projects and even more ideas to do, but no manpower to do it. Claude Code/Copilot provides the manpower and I’ve been actually finishing many of these small projects/prototypes. It makes programming fun again for me, as I just don’t have the time to spend a day writing yet another parser or a backend or setting up infrastructure for a new project, and Claude does it very well for me and I can focus on the actual problem at hand, design, etc. I found once I figure out a better design, I can tell Claude and it is able to refactor my code, but it can’t come up with the right design.

Regarding your project, yes, figuring out the right design for a compiler is hard. But at least with Claude you can iterate quicker on the design prototypes.

1 Like
13

Great, then we feel the same! Unfortunately, Claude Code completely broke last week and with it, it broke also a lot of lazy-fortran. I am switching now to codex and up to now it looks as amazing as Claude in the “good old day”. Currently working to get the critical bugs fixed one by one with scripts in GitHub - krystophny/prompts (Claude needed complex peer review system of agents because it kept deceiving the prompt, not necessary in codex)

1 Like