Ada, like Fortran, is a compiled, statically typed, standardized programming language supporting OOP that has often been used in military applications. Visually it looks like Fortran (no curly braces, but many lines end in ;). The following aspects resemble Fortran:
What most C-family languages call “functions”, Ada calls “subprograms”. Ada distinguishes between those which return a value and are truly “functions” and those which do not return a value, and are “procedures.”
For example, subprogram parameters can be either in , out , or both. in parameters are readonly, and while you can force passing by reference via specifics in the language, you often just ignore how this happens. Parameters are implicitly in , so you can omit that if you want.
Ada’s an obscure language. It’s been around for decades and strong opinions about it existed in the past, but overall it seems forgotten outside its niche. When I mention I made things in it, I’ve gotten baffled responses of “That language is still around?” Another comment was, “I’ve never heard of anyone else ever working, or having working in Ada.”
I’ve written code in a variety of languages, but Ada by far is the most bizarre and strangely familiar one at the same time. My intent was to mess around with it for a few weekends and move on, but it wasn’t the “dead language” I expected. There’s been a lot of modernization in the last couple of years, which makes it a surprisingly modern language to work in.
Hmm. Arguably modern Fortran has been an evolution toward a safer, more Ada-like language. Besides what I mentioned above, are there features of Ada that Fortran should emulate?
runtime-initialized module constants would be extremely useful and would enhance the safety of Fortran programs. These are constants that have to be initialized once at runtime (as opposed to compile-time), but should not be changed anymore throughout the life of the program. I have heard that Ada has such a functionality (don’t remember the technical term for it) but it is missing in Fortran. What I personally do, to ensure I do not inadvertently modify the value of such module constants after runtime initialization, is to prefix the names with mc_ to indicate the object is a module runtime constant whose value should not change anywhere else. But ideally, the Fortran syntax and compiler should take care of such cases, not the user’s naming convention which is error-prone.
I think a comprehensive test suite, to smooth out the rough edges of the large number of Fortran compilers, would be very helpful. Ada has a conformity test suite for each version of the language.
I was reading through the comments, and it has pros and cons to have a conformity test suite.
The Pro is that it will ensure all compilers are conforming.
The Con is that it can almost eliminate or harm new compilers as it would take years before they are “conforming”, and thus until people start using them.
To work around the Con, I would suggest to create a test suite that would be a “subset of Fortran, that is still usable”, and new compilers can target that one first, before attempting to be fully F2018 conforming.
To elaborate on the last point — would would we, as a community, suggest to be such a minimal usable subset of Fortran? It would be extremely helpful for LFortran and I am sure Flang also. I could even imagine a “ladder” of such subset. Currently the only “ladder” is F77, F90, F95, F2003, F2008 and F2018. But each of these I think is unnecessarily complex for a “usable subset”. The F77 I think is the simplest in some sense, but most programs there require fixed form parser, which is complex on its own.
Those are good points and valid concerns. I don’t think a Fortran conformance test suite should be quite so formal as Ada, which is used in projects that are deemed “high assurance” like aviation and military.
This isn’t to say Fortran is absent from those areas, only that it emphasizes mathematical and engineering concerns. Perhaps the test suite should emphasize parsing and syntax Modern Fortran code, and the standard library could be used as a secondary set of tests?
Regarding parsing, that’s easy — you just point the compiler to a file and parse it, and both Flang and LFortran can now parse most of Fortran 2018. It’s the other parts of the compiler that it’s good to test. Not just the runtime library, but all the semantics, modules, modfiles, code generation, etc.
Always good to remember Ada Byron Lovelace who with Charles Babbage was among the first, possibly even the first, modern programmers of computer algorithms: Ada Lovelace - Wikipedia
That test suite is available, but it is over 20 years old, and most current compilers will probably pass it (with the exception of those few tests that are not deliberately designed to cause “failure”).
As regards test suites, I have seen many discussions of that, including why the standards committee and the vendors (which have test suites) and the many tests derived from bug reports have not been combined and why commercial vendors would hesitate to use one, even including the gfortran tests, which are Open Source. How lawyers keep coming up in a discussion about a Fortran test suite is almost comical. Perhaps a joint project just between Open Source compilers, which currently probably need it more is feasible.
I think a simple beginning might be to extend the intrinsics descriptions project on fortran-lang
to include tests of the intrinsics, as some implementations are sub-optimal. It might expand interest in the descriptions, be a seed of a conformance test, and help Fortran implementations to provide robust intrinsics. SUM() is a simple example that has been discussed on this forum, where some implementations are just a straight-forward addition of the values.
There are a lot of Ada+PL/I+Matlab (which was doing what Fortran should have been doing for quite a while) features I would like to see; but I will not be holding my breath. PL/I has some good features too. There are things to learn from the history as well as the features from Ada (and PL/I); but you would get at least three camps with very different opinions that could each fill a book with their versions, so I would not even attempt it here.
One can use a function with no arguments as a run-time initialized constant. It can evaluate something disallowed in a parameter declaration. For example, this one can be used to check whether reading ‘NaN’ gives one of the IEEE NaNs or a different real not-a-number.
pure real(dp) function nan()
character(3):: cnan
cnan = ‘NaN’
read(cnan,*) nan
end function nan
Of course a function to be used as a runtime constant must avoid host-associated variables, but dp above has to be a constant, e.g. kind(1d0).