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 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.