The point is to make the language regular, i.e. to have the same style of arguments for every command.
In fpt the input stream is tokenised by the lexical analyser. The tokens are start-of-statement, label on statement, name, operator/delimiter, number etc. The lexer doesn’t know about keywords. The first stage of static semantics is to identify the keywords. This exposes a huge variation in the syntaxes of the different keywords. It does have a certain baroque splendour, but it looks archaic.
From our point of view the problem won’t go away - we will have to handle all of the syntactic variation forever. But I can understand why it can be hard to attract new users.
Not all the current inconsistencies can be explained by the legacy constraints. Both TYPEOF(x) and the ugly RANK(RANK(x)) have been introduced recently, without following the same logic.
RANK(x) is OK as an intrinsic, but as a variable attribute, RANKOF(x) would have been probably 1) more pleasant to read, 2) more consistent with TYPEOF(x)
We had this discussion when it came to backward compatible changes before. The question is: Do you want to have the best product based on today’s understanding or do you want to avoid breaking changes?
I’m strongly in favor of the first option: Learn from mistakes and fix them. I also acknowledge that breaking changes come at a cost, but Rust shows that there are solutions for that: What are editions? - The Rust Edition Guide. Optimistically, one can label the Fortran way as “never change a running system”, I call it polemically “punched card mentality” where ballast and glitches are dragged along for eternity because the cost for changes is too high.
It was not meant personally, I will remove it if it is considered to be inadequate.
“fast-fashion mentality” is dominant in web development, new frameworks come faster than Fortran versions. That’s even worse.
Stability/backward compatibility is mainly a feature for existing users, new users just see inconsistencies and don’t ignore them just because they exist for a long time.
We now stopped teaching Fortran in the Master of Mathematical Engineering — KU Leuven degree programmes and switched to C++. I personally don’t agree, but this decision is inline with the trend to consider C++ superior to Fortran for engineering and science applications.
I’ve been involved in teaching Fortran since the early 80’s and most people have to deal with existing code suites. This applies to both the academic and research communities (I worked in the UK university sector from 1975-2002) and the commercial and science and engineering communities. Legacy code is the starting point for most people, and people have to deal with it warts and all.
I am not convinced that anything needs to be broken. It would be worth looking to see whether an alternative regular syntax could be defined which did not conflict with any standard or widely used practices and could co-exist in the same code. Suppose, for example, that:
The arguments of all keyword directed statements were enclosed in parentheses
All aggregates of objects were enclosed in square brackets
All ranges were specified as start : end : stride
We would then have DO loops which looked like:
DO (i = 1:10)
WRITE statements which looked like
WRITE(mylun, [fmt = ‘(4I8)’, ADVANCE=“NO”, IOSTAT=wstatus], [i,j,k,l] )
The rules would apply to all statements, but the alternative syntax would need to co-exist with that of the current standard and with common practice. No doubt someone will tell me why the alternative WRITE syntax above wont work
If an alternative regular syntax were defined, tools would be created to convert code to it. This is a very easy process - the proposal is to change only the syntax, not the semantics. All that is needed is a compiler front-end and a simple code writer. We have done quite a lot of this in fpt, for example, changing:
(* to !
DEFINE FILE to OPEN
WRITE(TMPLUN'IREC) to WRITE(tmplun,REC=irec)
WHILE (STATF) DO to DO WHILE (statf)
DO UNTIL (i < 0) to DO WHILE (.NOT. (i < 0))
DOUBLE PRECISION to REAL(kr8)
DOUBLE COMPLEX to COMPLEX(kr8)
STATF .EQ. OLDSTATF to (STATF .EQV. OLDSTATF) (note parentheses)
REAL*8 to REAL(kr8)
REAL(8) to REAL(kr8)
None of these changes involved any of the semantic horrors we have had to deal with elsewhere - changing DATAPOOL to COMMON, moving DATA initialisation in COMMON blocks, changing COMMON to MODULE …
The first thing I would expect of any student handed a legacy code, warts and all, would be to format it and clean it up. This is not a dangerous process - if a compiler can compile it, the compiler front-end can tokenise it.
Please stop standardizing new syntax to the language so easily without a compiler prototype and without asking the community at large about their experience using the prototype in practice, because once it is in, we should never change it (in my opinion).
That’s all you have to do and it will naturally fix most of the issues raised in this thread.
I studied mechanical engineering from 2005-2010 and learned C and C++. Nowadays, the first language is often Python. Fortran became a niche language and it seems that the niche is getting smaller and smaller.
Legacy code is a limited resource and if Fortran is not considered for new projects, the legacy code of the future is not written in Fortran.
Legacy code is the starting point for most of the people we do courses for. These are some of the people we’ve done courses for AMEC, Warrington Aveva, Cambridge, AWE, Aldermaston
Centre for Ecology and Hydrology, Wallingford, DTU—Danish Technical University
Environment Agency, Worthing. Esso Petroleum, Fawley, JET—Joint European Torus, The Met Office, Bracknell and Exeter, National Nuclear Laboratory, Natural Resources Canada, Ottawa
Petroleum Geo-Services (PGS), Houston and Weybridge, QinetiQ, Farnborough, RAF Waddington, Ricardo Software, Risk Management Solutions, Rolls Royce, Derby
SHMU, Slovak Hydrometeorological Institute, Bratislava, Slovakia, University of Ulster, Jordanstown, Northern Ireland, VCS, Germany, Veritas DGC Ltd., Crawley, Westland Helicopters, Yeovil. On the niche language claim when Nag did the support for the HPC Hector service in the UK talks with their staff indicated that 85% of the work on those systems was Fortran and MPI based.
But I would ask one more thing. Seek a standard way of doing things so that a user will expect a familiar pattern of arguments and constructs. Respect the principle of least astonishment.
This is a most impressive list of customers - congratulations! We have considerable overlap, but more users on the left-hand-side of the Atlantic and south of the Equator.
The difference is that we have given few courses but have worked directly on many of the codes. Some of the work has been in migration, from VMS and MPX to standard Fortran, and some has been in QA and modernisation.
At many sites we have met the high priests of the Gould-SEL or VMS systems, with their young, acolytes who see Fortran as arcane and archaic. They are asking whether they can ditch Fortran for something more modern. So much will be lost if we cannot offer them something better. The semantics are wonderful and ever improving. The syntax needs work.
I agree that some of the people/organisations/companies no longer exist. I was very surprised about the Fortran/MPI usage of the Hector service. On the courses front quite a surprising number of the people attending have little or no programming experience. Some have a background in other languages, or Fortran 77. It is interesting how many are positive about modern Fortran by the end of the courses we offer.
Hi MarDie I incorrectly replied to JCollins, rather than you. I am relatively positive about the future of Fortran. Modern Fortran has a lot to offer. Coming from a computing services background and having had to work with other languages (C, C++, C#, Java, Python) I see a place for them as well.
@cmaapic: I hope I could say the same, because Fortran is ideal for engineering applications and I like it. My PhD researchers usually have a materials science background, the complexity of C++ is just overwhelming.
In general, the language is nice even though it has a few very rough edges:
no namespaces for modules
no exceptions. I know that they are misused a lot, but if used correctly they make life much easier
heterogeneous containers: dicts/hashes and lists.
and quite some small annoyances like implicit none.
Besides that, the main obstacle is in my opinion the ecosystem. That’s improving but still a long way to catch up with, e.g., Python.
Finally, I really think a systematic approach to correct glitches in the core language is needed. I disagree with @certik that prototyping will fully solve the issue. Mistakes and inconsistencies can’t be avoided and somehow one has to deal with them. I know that I repeat myself, but Rusts editions seem a great approach. Even with the different Fortran standards it would be possible: You have a legacy application: Fine, compile with --std=f77. You start a new project: use --std=f23. One can even make the decision file by file. Using that approach would almost completely remove the costs of backward incompatible changes. Only if one opts in for a new version, some adjustment to existing code bases might be needed.
I do this for my–admittedly small–application every 6 months when a new PETSc version is released. It’s some work, sometimes 1h, sometimes 2d, but in that way the PETSc team is able to always deliver the best solution based on today’s knowledge.
