Pathway to introduce straightforward features

[certik]

@FortranFan submitted this at #105, I moved it to a separate issue here, so that we do not derail a discussion at #105.

---

Sorry for going off-topic but to me this proposal looks rather straightforward and without serious side effects and any concerns or issues raised with something like this are going to be an overreach and can be heavily debated whether they're technical at all.

So the question is why does this have to Fortran 202Y whose timeline is likely in the year 2028 at the earliest?

That is, other than perhaps a project management type of decision by WG5 on the work-list toward Fortran 202X? But who should WG5 represent other than the "many users" who "have asked for a way to" need this? And since many other features of interest to said users have been deferred or rejected by WG5 for Fortran 202X anyway, why not carve out an avenue to add many other smallish features to Fortran 202X which will at least add some heft to what appears otherwise a rather dull revision considering the five years devoted to its development?

Suggestions such as these appear to me to be in the Just do it! category and the standards revision process must have a pathway to introduce any number of them into the language as soon as the work is completed like in an online development platform.

[certik]

This is related to #36. I agree. Currently we are in a mode "we select features and work hard on those few selected features until they are ready, delaying the release of the standard". Rather, we should move to a mode "we work on all features that the community wants, and when a feature is ready, it goes into the very next standard, which is released every 3 years no matter what".

[sblionel]

I very much understand the sentiment here. But this approach has been the ruin of us before, making continuous additions right up to nearly the end. The problems with this are 1) stretching out the schedule because NO feature, no matter how simple, has zero cost, and 2) it encourages others to keep up a steady of stream of "if you let X in, why not my Y?" This includes things I'd like to see added, and I've had to bite my tongue several times to avoid reopening the floodgates.

This is my first go at "running" a standard development process, and I've chosen to take a hard line on when we stop accepting new feature requests. Nearly all of WG5 supports this and we have made much more progress in meetings than before, where we kept taking time away from development and integration with discussions of 1+ items. For better or for worse, that's how we're doing it for 202X. (FWIW, John Reid, the previous convenor, has said to me more than once that he wished he had said "No" more often.)

Might it be different for 202Y? Probably - especially if this Github list is successful at accelerating development of features. I would want to see participation of more of the J3 folks who have long experience with the standard and who develop the bulk of the proposals to date. I'm uncomfortable that so far I seem to be the only one such here. It's definitely something I will bring up in February.

What I do very much want to avoid is Fortran becoming a "kitchen sink" language, full of everyone's pet features from other languages (or new). I think the current process is working well so far, and we've made a lot of progress, and I don't want to spoil that by changing the strategy mid-stream.

[gronki]

Sorry to break it but no. The current process is not good and Fortran needs to catch up urgently. The truth is that many of these "pet features" are more polished that these who made it into standard and are made fun of till these day.

If we have to wait for 10 years until 202y for simple features needed in the language urgently then we see the problem that is explained in the original post. I would see them published no later than 2 years. And if the current committee cannot do this then probably this is why it meets so much criticism from people who actually use the language.

sob., 30 lis 2019, 16:32 użytkownik Steve Lionel notifications@github.com napisał:

I very much understand the sentiment here. But this approach has been the ruin of us before, making continuous additions right up to nearly the end. The problems with this are 1) stretching out the schedule because NO feature, no matter how simple, has zero cost, and 2) it encourages others to keep up a steady of stream of "if you let X in, why not my Y?" This includes things I'd like to see added, and I've had to bite my tongue several times to avoid reopening the floodgates.

This is my first go at "running" a standard development process, and I've chosen to take a hard line on when we stop accepting new feature requests. Nearly all of WG5 supports this and we have made much more progress in meetings than before, where we kept taking time away from development and integration with discussions of 1+ items. For better or for worse, that's how we're doing it for 202X. (FWIW, John Reid, the previous convenor, has said to me more than once that he wished he had said "No" more often.)

Might it be different for 202Y? Probably - especially if this Github list is successful at accelerating development of features. I would want to see participation of more of the J3 folks who have long experience with the standard and who develop the bulk of the proposals to date. I'm uncomfortable that so far I seem to be the only one such here. It's definitely something I will bring up in February.

What I do very much want to avoid is Fortran becoming a "kitchen sink" language, full of everyone's pet features from other languages (or new). I think the current process is working well so far, and we've made a lot of progress, and I don't want to spoil that by changing the strategy mid-stream.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/106?email_source=notifications&email_token=AC4NA3OWPVG3N4T6VXYYBLTQWKBPNA5CNFSM4JTGYOVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQKX6Y#issuecomment-559983611, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3KCLASV2EFBCJYUHDTQWKBPNANCNFSM4JTGYOVA .

[sblionel]

I have said before, the majority membership of J3 and WG5 are users, not vendors. (And most of the vendor members are down in the weeds with their users on a daily basis.) It really doesn't matter what we do, someone will be critical. The 202X process was more open to users' wants and needs than any in the past.

A significant part of the delay in issuing new standards is the process required by ISO, which calls for multi-month letter ballots of a draft and what is supposed to be final. There's absolutely no way that a 2-year cadence could be followed unless the only things changed were fixing typos. Consider that the coarray enhancements in F2018 took at least four years to develop, changing significantly over that time. A lot of the work was done asynchronously to meetings.

[gronki]

I understand. Thank you for explanation of these limitations. Still I think maybe some features could get a fast track process. Can I ask how is the division of workload? Say we need feature X which is a simple function to do something. Does everyone discuss it at once? Maybe one person who is qualified could take this only one function as their main focus and prepare analysis and ready to vote project that does not need to wait years. Would that work?

sob., 30 lis 2019, 17:27 użytkownik Steve Lionel notifications@github.com napisał:

I have said before, the majority membership of J3 and WG5 are users, not vendors. (And most of the vendor members are down in the weeds with their users on a daily basis.) It really doesn't matter what we do, someone will be critical. The 202X process was more open to users' wants and needs than any in the past.

A significant part of the delay in issuing new standards is the process required by ISO, which calls for multi-month letter ballots of a draft and what is supposed to be final. There's absolutely no way that a 2-year cadence could be followed unless the only things changed were fixing typos. Consider that the coarray enhancements in F2018 took at least four years to develop, changing significantly over that time. A lot of the work was done asynchronously to meetings.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/106?email_source=notifications&email_token=AC4NA3KHMPVGCDUBIP6I2YLQWKIADA5CNFSM4JTGYOVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEFQMUWQ#issuecomment-559991386, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3KA7ZCXNBOWXIWRNPTQWKIADANCNFSM4JTGYOVA .

[sblionel]

Each meeting, attendees are split into "subgroups". A first pass at this is usually done by Bill Long, but at the meeting anyone can ask or offer to join a different subgroup. The subgroups are (if I have this right, even now I sometimes get confused):

• Data - deals with declarations, expressions
• HPC - coarrays and C interoperability
• JoR - I/O, intrinsics, execution control (The term JoR is historical, doesn't really mean anything now.)
• Interp - Interpretations
• Edit - Non-technical changes

Bill does preliminary assignments of all submitted papers to the various subgroups. Sometimes these assignments get changed as the paper is better understood. Each subgroup has a head. Different people have different areas of expertise; Bill usually heads HPC, Malcolm heads Data (and Edit and Interp nowadays). Dan Nagle usually heads JoR but I have sometimes, and I am usually there as that's the part of the language I know best. If the distribution of papers among subgroups is uneven (often), more people will be switched to the one with more papers.

Each day, after the initial plenary meeting, the subgroups separate to work on papers. Features generally need specifications and syntax, and subgroup members work on those. They will also discuss proposals and decide whether or not the subgroup recommends the proposal or not. Often new papers will be written as results of considering earlier papers, or issues that have arisen.

Each afternoon, the subgroup head reads off a list of papers that all are to read for the next day. Some are for vote, some have "straw votes" used to establish a direction, some are informational and some are flagged as "no action". At the next morning's plenary session each paper is discussed in turn and, if needed, votes taken. Often some minor detail will arise that requires a small edit, and the paper is passed "as amended" where that edit is agreed upon and then a final revision is made and posted.

When I built the current J3 web site, I added the ability to mark each paper with its status, and you can sort on status, making it easy to see if anything was missed. It used to be that Dan kept a spreadsheet that he updated twice daily, but this was a manual process.

Many members read papers as they are posted to the J3 site between meetings and may engage in discussion with the author.

It's very unusual for any proposal to come to J3 fully-baked, no matter how qualified the author. Most smaller items can get done in one or two meetings, but larger ones take more time. A major source of issues is often how the proposal works with the rest of the language, and it is here that the more experienced members have valuable insight.

For 202Y, I'd love to see us begin the process with developed proposals and not just one-liners. This github could be a way to do that.

[tskeith]

This is related to #36. I agree. Currently we are in a mode "we select features and work hard on those few selected features until they are ready, delaying the release of the standard". Rather, we should move to a mode "we work on all features that the community wants, and when a feature is ready, it goes into the very next standard, which is released every 3 years no matter what".

This seems to imply that implementors have unlimited capacity for new features so there is no need to prioritize them. (Or else it's fine to have lots of features in the language that aren't implemented yet.). I don't believe that is the case.

I think an important contribution of this project can be to decide which features are most important to get in (at least to this community).

[certik]

@gronki is 100% correct, that if we, as a committee, are unable or unwilling to get simple features like #105 (if there is an agreement in the wide community for it) in sooner than in 10 years, then we are not doing our job. It's that simple.

@sblionel has done a tremendous job making the committee's work more transparent, creating a website, thinking hard how the process can be improved, engaging here, etc. That is not a criticism of you.

@tskeith's point is also valid, that's why we have an issue #59 and indeed, we absolutely should not put every conceivable feature into Fortran. Only those that bring Fortran closer to its vision (as agreed by the wide community on the most popular issues).

[FortranFan]

@certik wrote:

.. @sblionel has done a tremendous job making the committee's work more transparent, creating a website, thinking hard how the process can be improved, engaging here, etc. That is not a criticism of you. ..

I absolutely second the above statement. My comments and questions in the original post are not meant as any personal criticism.

Rather my assessments are based solely on "the writing on the wall" appearing in clearer, bolder, and darker letters every day the Fortran standard is on the verge of becoming totally irrelevant (or it always was) in so many domains. So many code-bases get refactored away from Fortran altogether and a few that remain are left untouched in legacy FORTRAN which, in every instance I have reviewed, employs so many non-standard extensions.

So another question to ask after "For whom Fortran?" is "Of what use is the standard?" Especially if the supposed INCITS standards process - as understood by the current members - comes in the way of the Fortran language? And when so many of the widely used computing languages and paradigms - Python, Java, C#, R, MATLAB, Swift, and even C++ in its real usage - in the scientific and technical domains are unencumbered by INCITS in any way.

The situation is dire.

I find no manager financing a large, new project will now even consider 'modern' Fortran given its interminable feature-deficiencies. Imagine letting loose a team to work on a specific engineering or technology task using Fortran with a challenging but firm deadline where the coder backgrounds right from their high school days overwhelmingly given the education system (how many engineering schools or high schools teach Fortran?) tend to be in coding in non-standard C++, Python, MATLAB, C#, Java, Swift, R, Visual Basic for Applications (VBA), etc. (and especially when they are engineers and scientists who have to apply and advance their domain-specific knowledge the foremost during the execution of the task) and where they can't locate ready and easy ways to work with the diagonal of a matrix or split a 'string' into words or apply a type-safe and secure way to handle a myriad of computation specifications, the very basic aspects which have been resolved in other languages for decades.

Precisely when there is a particular urgency for Fortran to catch up, the WG5 decision with Fortran 202X is severely curtailing the much-needed growth of the language. In fact it now threatens regression among its monolingual practitioners professionally and computationally considering the general state of computing, say with the top 10 languages surveyed by IEEE (the largest body of engineers globally) that includes, as stated above, Python, C++, Java, C#, R, Swift, etc. and whose ecosystems advance at the proverbial "speed of light".

[sblionel]

I want to point out one important thing... Many, many customers have told me that they are not allowed to use a new feature unless said feature is supported in at least three (usually) mainstream compilers. What happens if you start cramming features into the standard is that implementors set their own priorities on which to do first, and it delays eventual support of the entire standard. This in turn means it can be many, many years before you're allowed to use feature X, even if it has been in the standard for a while.

I respectfully disagree with @FortranFan 's calling the situation "dire". Maybe this reflects his own circumstances and experiences, but it doesn't jibe with what I have seen in recent years among Fortran's wide customer base. Indeed, what I heard from customers was to keep the next revision small so that vendors had a chance to catch up, thus allowing them to make use of the new features sooner. The last thing I think any of us want to see is another Fortran 2008 situation, where even 10 years after publication there are only two full implementations (one of which is for a platform most don't have access to), and some of the most commonly used compilers don't even support all of Fortran 2003.

[certik]

I must agree with @FortranFan that the situation is indeed dire and I have seen a lot of the user base. The only reason Fortran is still being used is that so much is already written in it. But managers take every opportunity to move away from Fortran. And the sad part is that if I was in their shoes, I would probably do the same. I would suggest not to look the other way and rather try to understand the situation, otherwise we can't fix it if we do not even understand the problem.

[FortranFan]

@sblionel wrote:

.. For 202Y, I'd love to see us begin the process with developed proposals and not just one-liners. This github could be a way to do that.

Can some readers please look at items #37 and #46 and review the originals posts and the links therein to proposal papers and provide feedback as to whether they are "one-liners"?

[jacobwilliams]

Add me to the "situation is dire" group. In the NASA/astrodynamics/optimization world, Fortran is dying. Many of the classic Fortran programs and libraries with decades of heritage have been or are currently being replaced. Just a few major examples off the top of my head:

• JSC : FDS/FAS & SORT. Replaced with Matlab, Java, Julia, and some commercial tools
• JPL: DPTRAJ/ODP (replaced with C++ and Python), SPICELIB (currently being rewritten in C++).
• LaRC: POST (rewritten in C)
• MSFC: GRAM atmosphere model (rewritten in C++)
• GCFC: GTDS (I believe replaced with some C++ tools...but not quite sure about this one.)

I don't see any new modern optimization software being produced in Fortran anymore. (The classic SNOPT is an exception, it's still around but Fortran 77, and they have been working on a Fortran 2003 update for some time I believe). IPOPT was originally Fortran but was rewritten in C++. Amazing new libraries are being written in C++ (e.g., HIOP from LLNL, NLPAROPT from GSFC). There's also some excitement about Julia in this field.

There are a few holdouts. I'm holding down with fort with my Copernicus software (which is used by hundreds of people...most of whom probably don't know it's written in Fortran), as well as my opensource projects. But, the trend here is pretty clear. It's only going to get worse if another decade goes by with no significant improvements to the language or ecosystem.

[certik]

@jacobwilliams 100% agree, exactly the same experience at National Labs.

[cmacmackin]

I also agree that the situation is dire. I'm working as a research software engineer at the UK Atomic Energy Authority and new code is all written in Python or C++ (very occasionally Julia). While I have provided resources showing best-practice for those wishing to start a new project in Fortran, I know of no one who plans to do so. Codes currently written in Fortran are tending to be converted to Python for all except the most numerically-intensive parts (which get wrapped using f2py). Frankly, I would find it difficult to recommend anyone writes new software in Fortran, given the its verbosity, the poor compiler support for recent more powerful features, and the massive amount of time required to reimplement features which are built into most other languages.

It must be said that not all of this is due to the standards committee; the compiler vendors must take a great deal of the blame. They have failed to keep up with what new features are introduced. Gfortran at least has the excuse that it is primarily worked on by volunteers with limited time (although frankly, industry should start donating money and/or developers to overcome that). The commercial compilers really must do better, however.

Without meaning any animosity towards those on the committee or those working for the vendors, I fear that the current path will lead to the demise of the language in all but legacy code. The problem, I think, is this: at present the main customers for Fortran compilers are those with large legacy code-bases. Therefore, the vendors are compelled to cater towards those needs and will prioritise that over implementing new features or pursuing new, experimental, and/or innovative developments to the language. However, in doing so they are making it less and less likely that new projects/customers will use Fortran, given that there are other more powerful or productive languages they could work in. Ultimately I think this will spell the death of the language. Unfortunately, given the economic incentives, I also don't see an easy way out.

What we desperately need (as others have said) is an open source Fortran compiler which offers faster development of new features, including experimental ones. Not being dependent on legacy clients, it would be less constrained by the past and could even blaze a trail for the standards committee to some extent. It would be nice if gfortran could provide this, but given its massive and intimidating nature (not to mention that it is written in C) I think this seems unlikely enough people would have the skills to get involved. Perhaps Flang or LFortran will be able to fill this role, although we would still have the issue of resources; such a project is likely to struggle if it is done purely on a voluntary basis. However, something along these lines is surely necessary if we are to modernise the language.

[jacobwilliams]

My personal opinion... I think waiting for three compilers to support something before you use it is an extreme requirement, and Fortran shouldn't be held up by people that have a requirement like that. No one has a requirement like that for Python (the very idea would be absurd). Unfortunately, I guess the reason some people have this requirement is because the Fortran compilers I'm familiar with are usually riddled with bugs when a new feature is added (yes gfortran is done by volunteers so I don't complain about that. Intel is another story). If there existed a free and canonical Fortran compiler that was released along with the standard and was very high quality and guaranteed to work, then this wouldn't be an issue... but that doesn't currently exist.

[FortranFan]

Edit 12/6/2019: my earlier comments withdrawn.

@septcolor wrote:

.. Here again, do we users need to wait for the NAG compiler to implement it (with the implementation schedule unknown?) ...

I honestly believe waiting for certain compilers to catch up has dictated the technical content of Fortran 202X to that of a very minor revision. I have tremendous concern such a consideration will continue to adversely impact future development of the language.

[certik]

Thank you @jacobwilliams, @cmacmackin and @septcolor for your feedback. I agree, I have a very similar or identical experience as you have. I have no doubts it is like that at any major corporation and company, so the situation is dire. Most influential members on the committee currently unfortunately do not agree with us. The committee seems fine with the current trajectory.

I am not. I want to say very clearly, that I am not at all interested in the current trajectory of "managing Fortran's slow but steady disappearance". If that is the goal of the Fortran committee, then we need to change the goal. The goal should be to get Fortran used for new projects again, and to create a healthy ecosystem again.

And I also believe the tide could be turned (that's why I started LFortran, joined the committee, started this GitHub repo, etc.). I also agree that what is needed is to have a modern compiler, maintained by the community, and add all the new features in there, just like Python or Julia does it, and not need to wait until all other compilers catch up.

The wider community seems to agree this is the right vision. And so it would be very helpful if the Fortran committee could help us make the vision succeed.

P.S. To that end, @FortranFan please tone the rhetoric down a little bit. Let's try to be critical without being personal. We are all on the same team.

[FortranFan]

@certik wrote:

.. @FortranFan please tone the rhetoric down a little bit. Let's try to be critical without being personal. We are all on the same team.

Point accepted.

[Leonard-Reuter]

Just to add my experience even though it simply mirrors all the others: In theoretical chemistry community (and also theoretical phyics afaik), no new program is written in Fortran. People use Python and/or C++ instead. I really agree with @certik : We have to improve and adapt the language at a pace faster than now. Otherwise, Fortrans disappearance might actually come faster than you'd think. (Trying not to sound apocalyptic). I think, LFortran and especially this repo are really giving us a chance.

[pdebuyl]

Extra anecdote. Background: statistical physics, chemical physics, nonlinear dynamics, work at universities.

When I mention Fortran to colleagues, most of them wonder at the mere existence of the language. It is regarded as a relica, most people having only caught seen a glimpse of F77 if any. CPUs have become fast enough that one can prototype small simulations in Python or Matlab. It is annoying of course, because small scale computations implemented as Python loops take forever to run. There is no easy "start with Python then speed up" (PS: I know the libraries to accelerate Python code, my colleagues/students not) so that we are in a worse situation than the default Fortran + gnuplot/xmgrace of 20 years ago. Courses are now C++ or Python.

I'd like to mention a huge bonus of Fortran here: one can develop codes spanning several years of work, whereas in some other languages you'd be hit by a new incompatible version, a small numerical regression, a tool becoming unsupported, or whatever change of fashion. I know that code I write in Fortran is an investment. Scientists unfortunately can only acquire this point of view after many years of practice.

I think that the current Fortran has already gone a long way (mostly thanks to modules, defined types, and C interop). We should look, as others mention, at the idea that Fortran should remain a good option for new codes.

Besides the language itself, the stdlib initiative is excellent. We also need teaching resources that show how to use Fortran in a modern way (@milancurcic 's book, @certik fortran90.org , maybe extra "Fortran for starters" tutorials).

[jvdp1]

When I mention Fortran to colleagues, most of them wonder at the mere existence of the language. It is regarded as a relica, most people having only caught seen a glimpse of F77 if any. CPUs have become fast enough that one can prototype small simulations in Python or Matlab. It is annoying of course, because small scale computations implemented as Python loops take forever to run. There is no easy "start with Python then speed up" (PS: I know the libraries to accelerate Python code, my colleagues/students not) so that we are in a worse situation than the default Fortran + gnuplot/xmgrace of 20 years ago. Courses are now C++ or Python.

Same experience for me :(

[FortranFan]

135 appears a "classic" use case for this issue.

My https://github.com/j3-fortran/fortran_proposals/issues/135#issuecomment-573246670 in that thread got mischaracterized, however it's the truth in the current scheme of things no pathway to introduce straightforward features exists with Fortran 202X being "closed" and the subsequent revision, where some pathways might open up for straightforward features, is indeed 8+ years away from the present.

135 appears to be a simple Yes/No question.

• Is Fortran willing to reconsider the NAMELIST formatting aspect of embedded blanks in designators?

• If yes, is Fortran willing to "standardize" what is already supported by several of the processors tested by OP (Intel, Cray, PGI, gfortran) and which is very Fortrannic in that FORTRAN has supported embedded blanks in designators and more since its very inception.

What would be the technical reasons one would need anything more than a limited amount of time, say one WG5 meeting (that usually takes place over 5 working days) to answer the first question? Then if the answer is No, no further action on #135 would be necessary. But if it is Yes, why should it then take more than one or two J3 meetings, which too are usually 5 working days long, and one other WG5 meeting to answer the second question?

One would think a "straightforward" feature is one that does not appear to present any concern involving backward incompatibility, adverse impact, etc. Can #135 be a case study case in terms of how the readers can think through such matters? According to readers then, what are the potential reasons to view #135 as not a "straightforward" feature?

[certik]

I agree. Thanks for continuing the discussion here. We need to be able to bring such improvements in. Let's prepare a proposal for it, and get it approved by the Committee. Then let's convince the committee to include it in the next standard.

On Sun, Jan 12, 2020, at 6:44 PM, FortranFan wrote:

135 https://github.com/j3-fortran/fortran_proposals/issues/135

appears a "classic" use case for this issue.

My #135 (comment) https://github.com/j3-fortran/fortran_proposals/issues/135#issuecomment-573246670 in that thread got mischaracterized, however it's the truth in the current scheme of things no pathway to introduce straightforward features exists with Fortran 202X being "closed" and the subsequent revision, where some pathways might open up for straightforward features, is indeed 8+ years away from the present.

135 https://github.com/j3-fortran/fortran_proposals/issues/135

appears to be a simple Yes/No question.

• Is Fortran willing to reconsider the NAMELIST formatting aspect of embedded blanks in designators?

• If yes, is Fortran willing to "standardize" what is already supported by several of the processors tested by OP (Intel, Cray, PGI, gfortran) and which is very Fortrannic in that FORTRAN has supported embedded blanks in designators and more since its very inception.

What would be the technical reasons one would need anything more than a limited amount of time, say one WG5 meeting (that usually takes place over 5 working days) to answer the first question? Then if the answer is No, no further action on #135 https://github.com/j3-fortran/fortran_proposals/issues/135 would be necessary. But if it is Yes, why should it then take more than one or two J3 meetings, which too are usually 5 working days long, and one other WG5 meeting to answer the second question?

One would think a "straightforward" feature is one that does not appear to present any concern involving backward incompatibility, adverse impact, etc. Can #135 https://github.com/j3-fortran/fortran_proposals/issues/135 be a case study case in terms of how the readers can think through such matters? According to readers then, what are the potential reasons to view #135 https://github.com/j3-fortran/fortran_proposals/issues/135 as not a "straightforward" feature?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/j3-fortran/fortran_proposals/issues/106?email_source=notifications&email_token=AAAFAWDQO7VG7BIXGKLSZ4DQ5PBO5A5CNFSM4JTGYOVKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIXKTOI#issuecomment-573483449, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAFAWERQ4SHK52S3D6SF7DQ5PBO5ANCNFSM4JTGYOVA.

[sblionel]

In my position as WG5 Convenor, I am against reopening the work list for 202X. It is not clear to me if that is what is being suggested here, but if it is, there will be a strong pushback. One of the major criticisms raised in this "forum" is the length of time it took to ratify F2018 after F2010 - I presume this is the source of the "8 years" comment that has been made.

It is my firm belief, having been on the committee during that entire development time, that a major factor was continuing to "`1+" the feature list well into what should have been the final draft phase. When I was made Convenor, I decided that we were going to do it differently this time and set a firm cutoff for features, in the hope of getting the standard out in 3-4 years instead of 8. I got the approval of pretty much everyone on WG5 for this. The previous Convenor, John Reid, admitted to me that he wished he had said "No" more often.

Yes, I know that this means good ideas won't "make this train" and will have to wait for the next one. But the alternative, in my view, is worse, as there will be a steady stream of "just one more!" that takes away our limited resources to define and integrate, and risks making mistakes due to rushed development of what we might think is straightforward.

This forum is doing what I hoped for - collecting and vetting ideas for future revisions, kickstarting that process and allowing us to do more in less time.

[certik]

@sblionel thank you for participating here and trying to make it work. I agree with your concerns. I have a pretty pragmatic comment to this which I think will get all of us what we want.

I am against reopening the work list for 202X. It is not clear to me if that is what is being suggested here, but if it is, there will be a strong pushback.

Yes, that's what is being suggested --- however, not right now. The first step is to write a strong proposal for #135, get an agreement here at GitHub and submit to the Committee and get an agreement at the Committee. Then the next step (I think) is to also prepare the exact edits to the standard and again get everybody to agree to them. Even for a "simple" proposal like #135 this is actually a lot of work, that all has to happen first. Only then, if it is truly ready, I would consider that we have a frank talk about putting this into 202X. And yes, the answer at the Committee could be that we will only be able to put this into 202Y. But I am actually quite optimistic that people at the Committee might change their mind regarding this, if the feature is truly ready, meaning it does not require any more work from any Committee member.

Until then it's obviously not ready and I am not suggesting we open any kind of a work list and risk delaying 202X. We all want 202X to be out as soon as possible.

And we are all learning how to do this the most efficiently, we are just starting with this repository and we are just starting to build a community. All I am asking is that we trust each other that we are all putting our best faith effort to make this all work. And I think we are all doing exactly that, so let's keep working.

[sblionel]

Just to make it clear - WG5 could vote to allow new features in. I am just one vote on that. This isn't something J3 gets to decide on its own, though it can make a recommendation. If a change seems really important to get in now, I expect most WG5 members could be convinced to do so. #135 doesn't rise to that level, in my opinion.

I would be favorable to J3 discussion of any of these proposals, if it doesn't take away time from developing 202X. On #135 I'd be interested in opinions from people who have been on the committee longer than I on why that restriction was put in.