Indeed, that is a nice discussion. At the same time, all the warning that the Rust developers put there could well apply to C++, and yet lots of numeric code is moving to C++ from Fortran. IMHO the move to C++ makes even less sense than moving to Rust, and if Rust becomes a mainstream language, those moves will start to happen sooner or latter.
3 Likes
I agree with @Beliavsky. Let’s not judge here how other languages market themselves, because it is subjective and it is not going to lead to productive discussion. If there are specific misstatements, then we can correct them.
This is not a zero sum game, and just the fact that some other language goes up does not imply that Fortran must be going down.
We have all the tools to improve Fortran in our hands now. We have a website, forum, three open source compilers in development (or production), commercial compilers in both development and production, we have good ties with the standards committee, we are active on Twitter, we have a package manager, standard library, we are slowly creating an ecosystem of libraries, etc. The future of Fortran is completely in our hands. All we need to do is keep making progress on all these fronts.
20 Likes
Couldn’t have said it better.
2 Likes
I’m by no means a Rust expert, but I find the language very interesting and like @lmiq believe that it’s a language that really brings something new to the table. In “Fortran terms”, this is some highlights:
Memory Safety
Consider the following Fortran subroutine:
pure subroutine add_one(a, b, c)
integer, intent(in) :: a
integer, intent(inout) :: b
integer, intent(out) :: c
b = 10
c = a + 1
end subroutine
In Fortran it is perfectly legal to call it like this:
integer :: i , j
i = 1
call add_one(i, i, j)
write(*,*) j
Without inspecting the subroutine closely it would be tempting to say that this prints 2, but that is not the case. Since arguments a and b point to the same memory location (variable i) what happens is that i is set to 10 through the argument b and j becomes 11. This is known as aliasing. In Rust this sort of code is not allowed and would be stopped during compilation.
Strong Type System
This I struggle to explain well, but Rust has a lot of features in its type system that makes it possible to build libraries that are difficult to use incorrectly. In Fortran, if I make a library with a type :: clever_t for you then you might use it either as type(clever_t) :: c or as class(clever_t), allocatable :: c. In some cases this actually give slightly different behavior which could cause bugs because you used my library in a way I didn’t anticipate. Further, I as the library author might expect you to initialize the type with a constructor before using it - c = clever_t(some, arguments, here). There’s however nothing I can do to give a compile time error if you accidentally use the variable in its uninitialized form. Rust has ways of designing code so that some mistakes like this is impossible to do.
These things means that Rust has a very good potential for ensuring the code you write is correct which I find really interesting.
My interest in Rust is very much influenced by the type of work I do. I use Fortran to develop and maintain commercial software. Our users use it to make real decisions about their problems. Even though performance always is important in numerical software, most of the time I’m more concerned about its correctness than the ability to run a few CPU cycles faster. For this reason I would not consider a optionally typed language like Julia for my tasks.
9 Likes
Thank you for the interesting input
1 Like
It’s valid Fortran in the sense that it compiles and runs. It’s just invalid in the sense that the standard allows Fortran to give the wrong answer. This can manifest as a really hard to diagnose bug in big systems
1 Like
Precisely. A specification is worthless if there’s no tool to enforce it.
3 Likes
Right, the code is invalid from the standards perspective.
However, as a user I want the compiler to completely catch such bugs, either at compile time, or at runtime (in Debug mode).
4 Likes
My point is that from a user perspective, this is about as useful as a programming language that specifies it is undefined behavior for your program to have an even number of characters. Sure it’s my fault if this happens, but the language is still less useful and reliable as a result.
1 Like
My plan is to have an optional mode in the compiler that does not allow aliasing of arguments (or gives a warning). GFortran has -Waliasing, but it doesn’t seem to catch the case above on my computer. I don’t know if there is a legitimate use case where you want to allow aliasing of arguments to functions and subroutines. So I want to first get LFortran compilig most production codes, and only then start experimenting with checks like the above. But it seems either at compile time, or at runtime it should be possible to check that arguments are not aliased.
2 Likes
Could you point to the specific standard rule? It indeed looks like a side effect but still, the NOTE 5 in 15.7 section (Pure procedures) of the F2018 Interpretation Document (J3/18-007r1) states
The constraints for pure subroutines are based on the same principles as for pure functions, except that side effects to INTENT (OUT), INTENT (INOUT), and pointer dummy arguments are permitted.
Right.
I see, that’s an even harder question. My approach has always been to first have a fix in one compiler and see if there are any issues with it, before even attempting to propose a modification to the standard. Consequently, I am not in a good position to make proposals yet, but we are getting there quickly. 
2 Likes
The aliasing error in @plevold’s example can be handled in one of two ways. One way, which should work with all compilers, depends on noting that the first argument to add_one() is intent(in), so an expression can be passed as the corresponding actual argument:
call add_one((i), i, j)
Another way is compiler dependent; Intel Fortran, for example, has the -assume dummy_aliases option. With other compilers, lowering the optimization level may be tried. In either case, the user has to know the intent of the original coding. In this case, is the correct output 2 or 11?
2 Likes
In don’t exactly understand. If you can take a look at the code and readily see that it does not conform with the standard, shouldn’t all compilers throw an error there?
1 Like
The same question occurred to me several years ago. In the case of Fortran, the answer is “no”. There are errors that a conforming compiler is required to detect and act upon, and these are marked as “constraints” in the standard. The other errors are the programmer’s responsibility. The compiler is encouraged, but not required, to detect such errors.
It is common for larger Fortran programs to be split over several subprograms and source files. Some routines may exist only inside object libraries for which source code is not available. When aliasing is caused by using the same variable as more than one actual argument, the fault is at the calling point, but the error that this causes may only be possible to detect somewhere in the callee, the source of which may not be available. The compiler can certainly detect an instance where the same variable is used for more than one actual argument, but this is not by itself an error – there is nothing wrong with passing one actual argument several times when the corresponding dummy arguments are intent(in).
Recent versions of the NAG compiler, and Lahey’s 8.1 for Linux (no longer marketed) have the capability to detect aliasing of scalar arguments, if such checking is requested, and both the caller and callee sources are available for compilation.
2 Likes
There’s actually a really easy way to fix this: require compilers to handle aliasing if they can’t prove it doesn’t exist. This is really cheap (typically 1 pointer compare), and can usually be elided at compile time for cheap functions since they should be inlined anyway.
The suggestion I made isn’t one that would have been a good idea 60 years ago. Compilers have gotten a lot better since then which makes this a better design tradeoff than it was when the decision was originally made. It’s worth pointing out that I’m not specifying implementation. The specification is just “compilers must handle aliasing”. This strictly expands the valid set of Fortran programs, so is backwards compatible.
In the past 30 years, compilers for other languages have gotten much better at dealing with alias analysis, so as long as you don’t expect compilers to regress in quality, this is a relatively safe change to make.
Dangerous tools aren’t bad if you don’t have alternatives, but that’s not a good argument against making a tool safer where possible.
2 Likes
Some readers of this thread may find it worthwhile to read a thread about aliased arguments in comp.lang.fortran almost ten years ago. There are several short code examples in it that illustrate the difficulties that a compiler will have in detecting aliasing, as well as remarks from leading Fortran users, compiler developers and standards committee members. The lead example code is from Robert Corbett, a principal developer of the Sun Fortran compiler:
subroutine subr(b, c)
dimension b(10), c(5)
do i = 1, 10
b(i) = 2.0
end do
end
program copy
dimension a(10)
do i = 1,10
a(i) = 1.0
end do
call subr(a, a(1:10:2))
print *, a
end
What do you expect this code to output? What does your compiler deliver?
3 Likes
@jacobwilliams, perhaps that’s related to the fact that Fortran is not maintained by a single institution.
@sblionel do you think that Intel could be somehow interested in promoting some marketing initiative to empower the Fortran community?
@certik how is the relation, if any, of the Fortran compilers companies with our community?
1 Like
@Pap I have the same experience at work.
I agree and think we should not expect the experienced Fortraners to be the first on this initiative. We need videos it articles for beginners, with hot topics, the kind of ones students can make. I proposed a contest on this topic to promote such articles.
Of course, this is a complete parallel initiative to attract new users. Today’s students will be project managers tomorrow and will decide which language to use in their companies based on their knowledge.
1 Like