My idea is for the open source developers to come together and form an OpenFortran Foundation that is not beholding to ISO and would serve as a guiding force for Fortran language development focused on user needs. One of the guiding principles of the Foundation would be that Fortran development would be driven by the user community and not the commercial vendors. The current open source projects could continue as semi-independent projects but with each project having a specific agreed upon purpose or mission. The ultimate goal would be to combine the work product of the individual projects to form one reference compiler that would be the equivalent of Python and Julia. This approach would give the open source developers more latitude in telling the current committee to take a hike. Proposed changes/improvements etc to the language would have to be demonstrated with a working prototype based on the reference compiler before it is accepted as a new language feature or facility. I have no problems with the open source community and the commercial vendors taking different paths. People who need the comfort of a rigid standard can use the commercial compilers. At the same time anyone in the user community can take the reference compiler, implement a change they think is beneficial in a working prototype and present that to the Foundation for consideration for inclusion in a future release. I see this having a side effect of fostering more user involvement in compiler development. Nobody wants to waste their time trying to convince the current standard committee to adopt a change they consider worthwhile if they know that it will never be considered because it didn’t originate within the committee. Change is good. Competition is good. Let the open source community and the standards committee compete in the arena of ideas and let the best ideas win.
@everythingfunctional, @sblionel : I think my comments might have been perceived as slightly impolite due to the fact that I criticized publicly (instead of in private) the process of making last minute (what I consider) big changes. I worked with both of you probably for at least 5 years by now, both in person and remotely, and I am part of the committee too.
If there is anything I wrote that you consider impolite, please let me know, and I’ll change it. My understanding however is that it is not what I wrote, but the fact that I criticized in public instead of in private.
I worked very hard to help create this Discourse and the github proposals repository, as well as to reform the committee from within. My goal is to be able to communicate in public, in writing. Not just during in-person meetings.
I am fundamentally an optimist on this, and I believe, and my experience has been that it is absolutely possible and beneficial to have these discussions in public. And make these big decisions in public. It’s hard because written text is very limited for communication. Phone is better, video even better and in-person meeting the best.
However, the in-person meetings do not scale, and as shown above, it fails to get the wide community on board. It is mostly just communication. For example, all you had to do is write here proactively before people notice: “Just a heads up, we had to change the syntax from the arguably more natural {} to ^() due to reasons a), b), c), d). We had extensive discussions about the various pros and cons, and for now we chose ^() as the least bad so that we can move forward. However, it is not set in stone, please let us know, let’s discuss this, create a compiler prototype, get some experience with it, and if it is not workable, let’s change it.”.
When you are proactive in communication like this, it avoids a lot of the negative feedback from this thread.
The other thing I want to mention is that Fortran is bigger than what happens at any given committee meeting or anything I do. To be good stewards of the language, it is our collective responsibility to understand that and keep the door open to make such design decisions that the whole Fortran community can get on board, as much as possible, and at least try to get good wide consensus and keep the communication channels active.
Great perspective, @certik and thanks for your helpful engagement, @everythingfunctional and @sblionel. Onward and upward. Go team Fortran! 
@certik , I didn’t necessarily find the comments impolite, nor do I object to having the conversation in public. My concern is that the committee already receives complaints about moving slowly. If we couldn’t make decisions in meetings without giving time for community input I don’t think we could ever get anything accomplished. I’m definitely in favor of the committee being as open and transparent as possible. We can hopefully at least let people know what topics will be discussed in advance to provide opportunity for input from the committee. When it comes to the meeting though, it’s impractical to include those not in attendance in the decision making process. If you’ve been informed in advance about the topics, I don’t think it’s fair to complain that a decision was made without you.
One possibility that would seem to solve these problems in the future is to move feature discussion outside the purview of ISO. ISO meetings can’t be public, but there’s nothing to say that you can’t have an open meeting, recorded meeting 2 weeks before the ISO meeting, and then the ISO meeting only adds the conclusion from the open meeting to the standard.
This is a fair point. I think you do want some constraint on attendance and voting privileges, but I agree that the current barrier to entry for J3/WG5 is way too high. Unfortunately those of us on the committee have already cleared that bar, and are thus less motivated to change it. It is something that has been discussed once or twice and I don’t think there was opposition, but it’s sort of “above our pay grade” when it comes to actually making a change. INCITS and ISO set the rules, and as long as the committee is organized under them we have to follow the rules.
The problem is not that the original paper submitted was accepted or rejected. I reviewed it and I was fine either way.
The problem is that a new feature (syntax) was submitted and voted on the same day (?).
I think the committee should not create a new feature (syntax) at in person meeting and vote for it at the same meeting. Small edits / fixes are fine. In order to move forward, the committee can say “^()” is preliminary, the decision will be made later. But that’s not what happened, the decision was made already.
We have already fixed that problem with the incubator repository: GitHub - j3-fortran/fortran_proposals: Proposals for the Fortran Standard Committee, which is moderately used to discuss new features and prepare proposals. The ISO committee then (ideally) approves / denies or provides feedback. Unfortunately this process was not followed in this case and that’s what I am suggesting the committee does (to discuss features in public, vote in private ---- it can and should discuss in private too, as long as the feature was proposed and discussed ahead of time online).
I don’t think that’s feasible. It would invariably drag out the standard revision process indefinitely as we’d have to rehash every paper and never get a chance to actually vote on them. That’s especially true if the particular symbol chosen for a specific element of syntax is considered more than a small edit.
I can appreciate the request for the committee to be more open and inclusive, and I often advocate that we try to be even more so. Unfortunately, there’s no way around saying that the cost of being involved in the decision making process is attendance at the meetings. There’s just no other practical way of doing the work. Virtual attendance is always an option, so hopefully we’ve at least lowered that barrier as much as we can.
I hope I don’t sound like I’m being dismissive here. I’m not trying to be. I still value your, and the rest of the community’s, opinions on these things and I don’t want to discourage anyone from giving feedback.
I appreciate your feedback. I am glad you raised this point, it’s indeed at the core of the problem here. I believe the opposite: I think it is absolutely possible.
In the above case, all you had to do is pass the paper, but set the actual syntax as placeholder, then propose the syntax options, let the community a chance to give feedback, then set the syntax at the next meeting. In fact, it was already passed as {} at the last meeting, and I heard no objections to it, so this is just really unexpected, and in my opinion unnecessary. If something is already prototyped in the compiler I believe for almost a year now, I don’t think it should be changed on a whim like this without consulting the compiler developers who prototyped it. If I knew this was on the agenda, I would try to make it and argue against it, I didn’t even know this would happen.
I believe and have always advocated that the “unwritten” rule should be that all significant features are prototyped in a compiler first. And I arranged and funded this prototype. I am not asking anyone for extra work (I know it is a lot of work to prototype a feature, especially this complex like generics). I was really hoping the committee (yes, I am part of it) would work with me on this one case, where we actually have a prototype.
Unfortunately, based on this action I take it that it is not a priority for the committee. You said so above as well, using different words.
Again, I am an optimist and I think in a few years it will be a priority to have a compiler prototype first before passing syntax. We are just not there yet with the process.
I admire your optimism @certik. LFortran is bound to be a great success. Thank you for the great and important work you do!
By the nature of where we are in the process, this is not far off from the effect of what happened. No edits to the standard have been proposed and voted on, let alone made in any drafts, so if the community feedback really is to demand {}, we can still vote to change it with little impact on the progress made so far.
If anything you might have been more inclined to argue this in February, because the syntax in the prototype implementation of LFortran is actually not {} for template, instantiate, requirement or requires. None of the examples on dev.lfortran.org use {}. If anything our reversal back to () means those examples are still good (at least in that regard). There are other, more substantial ways in which the LFortran prototype doesn’t match the “approved” syntax, and those changes were made much less “suddenly”.
I agree, and I very much appreciate the time and effort you’ve taken to work with us and provide a prototype. It’s been quite valuable. I wish there were some way to find the resources to develop and keep these prototypes up to date as the design progresses.
So you are advocating for a schism in the Fortran world (let’s say a fork, given the context :)). Do you really think that Fortran is strong enough to split into 2 smaller communities? I don’t, and I’m even sure this would be killing it for good.
Among the 3 open-source compilers at the moment (gfortran, flang-new, and lfortran), only gfortran is mature. And yet we know that they lack contributors to implement the latest features on time and to fix the various issues. The two other ones have already more than enough work before being mature. So, who will contribute to the “reference implementation”, implement the new ideas, etc?
Again, what does prevent people implementing now new features in the current open-source compilers ? Why would it suddenly change?
LFortran is making progress much more quickly than the other 2 you’ve mentioned. With a modern compiler architecture and actual, active development, I would back LFortran >> gfortran in 10 years or so.
Flang has never been a usable compiler as long as I’ve known about it. Only the vendor versions from AMD (AOCC just ships flang) and Intel (ifx is LLVM based now I believe?) ever worked, they they both always had issues as well.
Can we perhaps support an available external meta-programming language?
Fypp seems to be a good initial solution, in this pursuit, so if open-source/commercial developers use it more, then eventually comercial vendors (compiler developers) will also pick it up for support and improvement.
Since we use generics mostly for code generation, Fypp seems to be good enough for this task. A compiler front end would only need to parse the Fypp grammar and de-sugar it into standard Fortran code.
This would not require adding any new complexity to the Fortran standard.
Maybe yes, maybe no, but the situation 10 years in the future was not my point…
To keep the prototype up to date, simply report all changes at Issues · lfortran/lfortran · GitHub, or send us a draft PR with the changes to our tests.
The syntax changes are relatively easy to fix.
I guess there are always two ways to look at things. I am personally happy with our progress with LFortran, and happy that you mention it in the same sentence with GFortran and Flang, that was unthinkable just a few years ago. I agree with you however that we first need to deliver it from alpha to at least beta (or more) in order to get lots of users and only then we can start talking about using it to drive Fortran ahead. But we’ll get there.
Well, I think it kind of is the point. If you want to harvest wheat, you need to plant it first months ahead and take care of it. If somebody comes to me that they want flour now, and I don’t have any in my storage, it means I failed to plan. I think that might be your point, that the Fortran community failed to plan for the future and plant these compilers sooner. I would agree. 
In my opinion, it’s how to organize the open source community so that it can deliver. It’s more of a social problem rather than a technical one.
If anyone in this thread wants to join us to get to beta sooner, please contact me anytime. Compiler development is very interesting, it’s like a puzzle to design it well. But it’s not complicated. Anyone can help us, you don’t need prior compiler experience.
From my experience with the UK university sector, UK research organisations and the commercial scientific sector Intel dominates the desktop compiler usage. Looking at HPC Cray and IBM feature heavily where people are prepared to pay for a complete package, generally based round Fortran and MPI. For people who ‘role their own’ Intel MPI is widely used. In terms of standard conformance Cray, Intel and Nag have high conformance levels. Other people on the list obviously have different backgrounds and experience.
I want to respond to this specifically, as I can’t disagree more strongly. The only barrier to being a member of J3 is the desire to ask an existing principal member to add you as an alternate - that’s it, no cost. This gives you the right to attend J3 (and WG5) meetings and to participate in discussions through all channels, including virtual meeting attendance. The only thing you can’t do as an alternate is vote if your principal also votes. The majority of attendees at J3 meetings are alternates!
If you feel strongly enough about the future of the language that you want to become a voting principal, then there are barriers, including cost. The specifics vary by country - in the US it’s paying a fee (currently $1350/year for organizations with less than $1 million in revenue - there is no lower cost alternative for individuals.) There are currently two J3 members who joined on their own: Gary Klimowicz and myself. (Bob Corbett had been a third, but for personal reasons is no longer doing this - he’s been given Emeritus status, an INCITS thing for long-time members that allows him to participate but not vote. ISO does not recognize Emeritus status.)
WG5 is what really matters, “J3” is in the end a US contractor only to WG5 on the technical work on Fortran (yes, go figure!").
With WG5, having a “seat at the table” and being able to communicate and have any influence on the direction that matters to Fortran is too difficult.
The barrier to entry to WG5 is way, way too high, so high that it’s entirely unclear how one can even make it there and even stay there!!
It is why I repeatedly request the Community members to watch this funny skit - No Soup for You! from a popular erstwhile popular TV show, a sitcom, a precursor to reality shows in the US and to understand the “no seat for you!” refrain that is too much of a reality for many.
And in the craziest, mind-numbingly stupid manner, ISO and its working groups, especially WG5 for Fortran, is organized according to “national bodies”, a la "League of Nations after WWI or UN and affiliated three-lettered orgs after WWII, such as US, UK, Japan (Canada, etc.) whereas no one, entirely no one, in the computing domains globally, especially around programming languages give too hoots about nationality or any organization, however soft or superficial, around national origin.
And so many Fortranners in the Community, from Asia including China and India to Czech Republic to Nigeria to Russia to South Africa to Zimbabwe - almost all that have far, far, far younger computationally minded technologists and scientists with advanced appreciation of how computer science and programming workflow are advancing - have no clue how to get their voices heard or represented at WG5 and for the language to take a direction that advances with them.
And no one, absolutely no one in WG5, is truly helping with this. Instead, it is all about using every whining, cry-baby tactic - people are “throwing stones”, they are not being “polite” - all toward “status quo”.
Seriously, what is up with all this?! What happened to “grow some skin”!?
And a fundamental question is why does the Fortran language development have to be subjected to and limited by WG5 in year 2024?