Delete Fixed-Form source format

[jacobwilliams]

It's long past time. Like implicit typing, fixed-form source is a massive embarrassment to modern Fortran that needs to go.

Provide a canonical fixed to free conversion script (see also Python's 2to3).

[certik]

I agree. It might be that compilers will support it for a long time for practical reasons, but the standard should simply say that fixed-form is deprecated and provide a canonical conversion tool that works with any code. That way the community will simply move code over (automatically).

However I would not use Python 2 to 3 as an example, as that script didn't actually work properly, due to the dynamic nature of Python and caused projects to invest insane amount of efforts to do the port. See my blog post with details: https://ondrejcertik.blogspot.com/2013/08/how-to-support-both-python-2-and-3.html. On the other hand, for the fixed-form, I think there might be a way to do this fully automatically and robustly --- but we need to do try this and ensure it works with any code out there, before deprecating fixed-form.

[FortranFan]

@certik wrote:

.. the standard should simply say that fixed-form is deprecated ..

The standard currently marks fixed-form source as obscolescent. There is a section in the standard for deleted, but there is no deprecated. Don't know if any ISO or INCITS considerations come into play here when it comes to these kinds of classification.

There appears an extremely strong resistance to mark features as deleted.

But the advantages of deletions are obvious: once something is deleted, the standard text (e.g., section 6 in current standard) no longer needs to cover that feature plus a compiler implementation, especially a new one, can decide not to support those deleted features. This might free up development resources to focus on new features while attracting certain customers (I know of some) who want nothing whatsoever to do with legacy aspects and want their code as well as compiler tool chains to focus exclusively on modern coding practices.

[jacobwilliams]

Delete it! :)

[klausler]

Production Fortran compilers don't have the luxury to delete features that paying customers are using, standard or not. Fixed form isn't hard to implement, it's still in use, and it's not going to leave the actual Fortran language, so removing it from the standard document just makes its specification harder to find in the future.

[milancurcic]

@jacobwilliams Proposals like this must have technical arguments. What's the problem with fixed form and what would be the benefits of removing it from the language? What would be the costs?

[gronki]

Well I think stupid line restrictions that make free form not actually free are more of a concern.

Dominik

wt., 10 gru 2019, 20:03 użytkownik Milan Curcic notifications@github.com napisał:

@jacobwilliams https://github.com/jacobwilliams Proposals like this must have technical arguments. What's the problem with fixed form and what would be the benefits of removing it from the language? What would be the costs?

— 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/108?email_source=notifications&email_token=AC4NA3OLFLMXH65IZJJ5CDDQX7RXRA5CNFSM4JYYZB4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGQL7KI#issuecomment-564182953, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3NPLO7O3CJJEISKNLTQX7RXRANCNFSM4JYYZB4A .

[FortranFan]

@gronki wrote:

Well I think stupid line restrictions that make free form not actually free are more of a concern. ..

Not sure what the above statement refers to.

With respect to Fortran 202X the next standard revision, WG5 has thankfully approved at the Tokyo meeting the following specifications for free-form source:

3 Specifications

A source line contains at most ten thousand characters.

A source statement contains at most one million characters.

Processors are required to be able to report too-long lines.

Continuation is unchanged, except that the limit of 255 is removed.

Barring any surprises during any further development of Fortran 202X work-list by J3 or reconsideration during subsequent WG5 meetings which, I think, would be unlikely, Fortran 202X should considerably "free up" the source form.

I believe Fortran 202X development with US01 worklist item on "Allow much longer statement lines and overall statement length" is a real quick grab of a low-hanging fruit with a language development that should alleviate any pending concerns with free-form source by actual coders as well as any that might arise with machine-generated code.

Readers can thus view free-form source as a mostly (if they aren't inclined to accept as fully) solved problem) and focus back on the original post with fixed-form source

[rweed]

Doing the most basic conversions required to transform a fixed source file to a free format one (ie changing comment cards to ! and continuations) is actually fairly trivial. I wrote my own code (in Fortran) to do that 20 years ago. Most current Fortran books suggest a strategy for continuations of placing an ampersand in column 73 on the continued line and ampersands in column 6 for the continuation. Detecting continuations is also trivial (just look for characters in column 6). The hard part of conversion though is dealing with what I call Stupid Programmer Tricks (ala Lettermans Stupid Human Tricks) where folks insisted on inserting white spaces between characters in reserved words etc. My "favorite" one was in a very large DoE program where one of the programmers (I think a grad student or a post-doc who didn't know better) thought it was jolly fun to put spaces between the letters of subroutine and the subroutine name ie S U B R O U T I N E M A T M O D. The real complexity comes when you want to shift things over to column one and then refactor the code to some indentation pattern that suits your programming style. Also if you want to lower case on all or some of the text to get away from the ALL UPPER CASE shouting, you have to deal with detecting and handleing character strings where you might not want the case to change. Still all of this can be handled by a competent Python/C++/Java (and even Fortran) programmer or any one (on Linux) with sed/awk and bash scripting skills. Going up to the next level and generating a tool to do a complete "makeover" that will convert DO loops to block constructs, change GOTOs to If/Then/Else is a much harder task and probably requires using the current compiler front ends and the ASTs etc generated as the first pass. Maybe some tools to do this can be written for LFortran and flang/f18 using LLVM but I know very little about LLVM so I'll let the experts comment on that.

[ivan-pi]

Don't any of you have those days where you feel like taking an old 1966 dusty deck in fixed-form source format out of the closet and having it compile smoothly with the current Fortran compilers? ;) It is what I do occasionally on weekends (like for example here: https://github.com/ivan-pi/stroud_quad).

I agree with @milancurcic that we need some technical arguments. I don't see fixed-form as an embarrassment and most people learning Fortran start using free-form directly (or at least I hope so!).

I can perhaps see a technical argument, that currently compilers assume .f files are in fixed-form, leading to the problem that @sblionel blogged about: https://software.intel.com/en-us/blogs/2013/01/11/doctor-fortran-in-source-form-just-wants-to-be-free. Maybe this discussion should be about standardizing the file extension instead, like @jacobwilliams has written about previously (see here http://degenerateconic.com/fortran-file-extensions/ ).

If fixed-form was removed/deprecated then we, modern free-form Fortran people, could again use the .f file ending, instead of defaulting to .f90 (which we use just out of convenience since it directly works on both the Intel and gfortran compiler, without the need for extra compiler flags).

[sblionel]

When we use the term “deprecated”, this is what the standard calls “obsolescent”, marking it as a candidate for deletion. Deleting a feature doesn’t magically free up something for redefinition, and NO compiler is going to remove support for fixed-form even if it gets deleted.

I would be delighted to find a way out of the mess we got ourselves into in 1991, but easy compatibility with decades-old sources is a major strength of the language, and I would not support anything that hurt that.

[jacobwilliams]

The reason is not entirely technical (although there are some technical reasons). Sure, for some people it's great that they can still compile their 50 year old code without modifications, but I think in the long run, it's very bad for the future of the language.

People are not choosing Fortran anymore. Young people are not learning it. Most people still equate Fortran with FORTRAN 77. One of the reasons for this is the vast amount of FORTRAN 77 code out there in the wild. Look at all the old FORTRAN 77 code that has been wrapped via SciPy. People see this stuff and think that's what Fortran is (and they know that they want nothing to do with it). It would be better if this old stuff just wasn't compilable anymore. Then people would either just abandon it (which is going to happen anyway at some point), or modernize it.

Backwards compatibility is great, but at some point it's time to move on. The time has long passed. People complain about the Python 2-3 transition, but in the end everyone is going to just deal with it. Python 3 probably has more users than all of Fortran, and conversion from fixed to free form is not nearly as difficult as converting from Python 2 to 3 (not even close). That's why an official conversion routine would be vital.

I know the committee doesn't agree, but getting new people onboard should be more important than backward compatibility. I see fixed-form source (along with implicit typing and other atavistic nonsense) as a gangrenous limb that needs to be removed before it kills the patient. :)

[klausler]

The reason is not entirely technical (although there are some technical reasons).

What are these technical reasons?

[jacobwilliams]

It seems like I've seen some discussions here about new features and worrying that some things aren't possible because of some limitation of fixed-form source? Somebody correct me if I'm wrong.

[gronki]

Yes I definely remember such arguments too although I can't bring up particular features or links. But it was mostly regarding syntax simplification related topics (along the lines of proposal X can't be done because fixed form does not see spaces blah blah blah). Maybe someone can help out here.

śr., 11 gru 2019, 20:39 użytkownik Jacob Williams notifications@github.com napisał:

It seems like I've seen some discussions here about new features and worrying that some things aren't possible because of some limitation of fixed-form source?

— 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/108?email_source=notifications&email_token=AC4NA3JKRXH7RU3JUG7KXG3QYE6YNA5CNFSM4JYYZB4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGUKKEI#issuecomment-564700433, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3OOUF7TNZLVRF3WGBDQYE6YNANCNFSM4JYYZB4A .

[gronki]

I'm all for killing old code. If Fortran might die too its a risk worth taking. It is dead anyway and we are just trying to revive it.

śr., 11 gru 2019, 20:53 użytkownik Dominik Gronkiewicz gronki@gmail.com napisał:

Yes I definely remember such arguments too although I can't bring up particular features or links. But it was mostly regarding syntax simplification related topics (along the lines of proposal X can't be done because fixed form does not see spaces blah blah blah). Maybe someone can help out here.

śr., 11 gru 2019, 20:39 użytkownik Jacob Williams < notifications@github.com> napisał:

It seems like I've seen some discussions here about new features and worrying that some things aren't possible because of some limitation of fixed-form source?

— 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/108?email_source=notifications&email_token=AC4NA3JKRXH7RU3JUG7KXG3QYE6YNA5CNFSM4JYYZB4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGUKKEI#issuecomment-564700433, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3OOUF7TNZLVRF3WGBDQYE6YNANCNFSM4JYYZB4A .

[FortranFan]

@jacobwilliams wrote:

It seems like I've seen some discussions here about new features and worrying that some things aren't possible because of some limitation of fixed-form source? Somebody correct me if I'm wrong.

Glad this point has finally surfaced and it's OP who has brought it up! I was waiting for it and I had deliberately kept quiet on this front in my first response upthread since I expected that to bring out all the usual non-technical counterarguments to pop up as they have. Which itself is most ironic given the premise of wanting technical arguments for a request to move forward.

From what I see given how the Fortran standard and its bearers understand matters (perhaps using ISO/INCITS considerations, as to whether that is pursued rightly or wrongly is a separate but legitimate debate), one is left with a binary proposition: no deletion of fixed-form source essentially implies continued support of it. And effectively then, every decision of all new features in the language while fixed-form source continues to be NOT DELETED, particularly at the customer-facing level meaning the syntax which is what the persevering practitioners of Fortran dabble with, is impacted and even held hostage by the peculiarities of that fixed source form.

Consider the current work by J3 on enumerations and see this paper: https://j3-fortran.org/doc/year/19/19-249.txt:

• Now, there were some good suggestions during the last meeting in Las Vegas on the requirements and specifications of this new feature and how to also allow compact declarations of an enumeration type along with its enumerator members e.g., for simple cases, something supported by many popular languages in scientific and technical domains such as Java, etc..
• Unfortunately such suggestions could not be considered and among the reasons for that was the language rules of fixed-form source.
• It appears highly likely what J3 will develop and what WG5 will approve for Fortran 202X toward enumerations is a most limited Pascal v1980 style facility (e.g., no ability to specify the value of enumerators UNLIKE all the top languages per 2019 IEEE survey) BUT with considerable VERBOSITY to boot - I'll be laughed off my domain if I show the ensuing enumeration facility in Fortran around year 2030 or whenever the compiler support for it finally arrives.
• The pernicious impact of fixed-form source would have played no small role in this abomination.

I think OP has legitimate merit with the request here.

[klausler]

@jacobwilliams wrote:

It seems like I've seen some discussions here about new features and worrying that some things aren't possible because of some limitation of fixed-form source? Somebody correct me if I'm wrong.

Glad this point has finally surfaced and it's OP who has brought it up! I was waiting for it and I had deliberately kept quiet on this front in my first response upthread since I expected that to bring out all the usual non-technical counterarguments to pop up as they have. Which itself is most ironic given the premise of wanting technical arguments for a request to move forward.

From what I see given how the Fortran standard and its bearers understand matters (perhaps using ISO/INCITS considerations, as to whether that is pursued rightly or wrongly is a separate but legitimate debate), one is left with a binary proposition: no deletion of fixed-form source essentially implies continued support of it. And effectively then, every decision of all new features in the language while fixed-form source continues to be NOT DELETED, particularly at the customer-facing level meaning the syntax which is what the persevering practitioners of Fortran dabble with, is impacted and even held hostage by the peculiarities of that fixed source form.

Consider the current work by J3 on enumerations and see this paper: https://j3-fortran.org/doc/year/19/19-249.txt:

• Now, there were some good suggestions during the last meeting in Las Vegas on the requirements and specifications of this new feature and how to also allow compact declarations of an enumeration type along with its enumerator members e.g., for simple cases, something supported by many popular languages in scientific and technical domains such as Java, etc..
• Unfortunately such suggestions could not be considered and among the reasons for that was the language rules of fixed-form source.
• It appears highly likely what J3 will develop and what WG5 will approve for Fortran 202X toward enumerations is a most limited Pascal v1980 style facility (e.g., no ability to specify the value of enumerators UNLIKE all the top languages per 2019 IEEE survey) BUT with considerable VERBOSITY to boot - I'll be laughed off my domain if I show the ensuing enumeration facility in Fortran around year 2030 or whenever the compiler support for it finally arrives.
• The pernicious impact of fixed-form source would have played no small role in this abomination.

I think OP has legitimate merit with the request here.

If one actually goes and reads the linked paper, one will see that fixed-form is used as a reason for requiring the keyword ENUMERATOR to appear before a list of enumerator names; in the absence of the keyword, a sole enumerator name might be misinterpreted as another keyword statement. Retaining the keyword seems like a good idea for free-form source too for error recovery reasons, so I don't think that fixed-form is exactly constituting a major barrier to technical progress in this case.

And you need to dramatically reduce the hyperbolic gibbering if you want this Fortran implementer to spend more time perusing this site. The good ideas are getting buried.

[certik]

@FortranFan's main point is valid, that fixed form was used as an argument why something cannot be done in 19/19-249.txt. If fixed form didn't have to be considered, perhaps the ENUMERATOR keyword would still be necessary for other reasons, as @klausler indicated, but perhaps not. However let's discuss that at #11.

@FortranFan please try hard to stick on topic and just discuss technical arguments in issues, otherwise every issue becomes buried and people stop participating here. If you want to discuss your wider points, just open a new issue and link it. But for already open issues that somebody opened to discuss a particular topic, please try not to derail the discussion.

[klausler]

Some real-world data on the cost of supporting fixed-form source in a compiler:

The parsing phase of the f18 compiler comprises 21373 lines of C++ code today; this phase recognizes Fortran programs and represents them in a parse tree data structure, which is constructed in memory prior to the following phase of semantic analysis. Fixed-form source affects only the part of the parsing code that preprocesses and normalizes the source in memory (stripping comments, joining continued lines, &c.) prior to running the recursive descent backtracking parser proper.

I searched through this code to count the lines that I could delete if fixed form source did not exist, and came up with a total of 250 lines, many of which were comments or just }. In the parser proper, fixed form affects two lines of source (they suppress a warning about missing white space where free form requires it). And there's roughly 20 lines of code elsewhere that manages the setting and clearing of the flags that indicate fixed-form source.

So that adds up to about 1.3% of the parser, which itself constitutes about 1/3rd of the f18 front-end.

[sblionel]

I cannot think of any features proposed that were rejected because of fixed-form's existence. (I don't count syntax that was revised for fixed-form compatibility.) Keep in mind that every compiler implementor I have spoken with on the topic of deleted features has said that they must continue to support deleted features. Deleting features provides no benefits and actually adds complexity for implementations which have to figure out how those features continue to work with the rest of the standard.

I do not agree that fixed-form source is why (allegedly) young programmers are not learning Fortran. I also disagree with that basic premise. While Fortran is not often taught in the US, in favor of sparkly languages not common in production environments, it is widely taught in Europe and Asia. This isn't the standard's fault.

My recommendation would be to "save your strength" and advocate for new features that will support the programming paradigms you'd like to use.

[FortranFan]

@certik wrote:

.. @FortranFan please try hard to stick on topic and just discuss technical arguments in issues, ..

May I please see some consistent adherence and application of this? The issue I notice across many threads here and it's one of non-technical counter-arguments to original posts. A basic fact with Fortran, nearly 3 decades after Fortran 90 revision, is that when it comes to certain legacy aspects such as implicit typing, fixed-form source, etc., the requests and suggestions to move forward as in the original post here and which allow the language to progress more freely are overarching considerations and can scarcely be put forth using any technical points given how the support toward the legacy aspects permeates across the standard, its development, and implementations in many subtle, hidden, and now 41 years after ANSI document on FORTRAN 77 in overwhelmingly harmful ways.

Under the circumstances, it's those making counterarguments who should have to strive to be technical, particularly from any of the points listed toward "creating a positive environment" under https://github.com/j3-fortran/fortran_proposals/blob/master/CODE_OF_CONDUCT.md. Otherwise,

I fail to see anything technical in the arguments posted counter to the original post here: https://github.com/j3-fortran/fortran_proposals/issues/108#issuecomment-564172206, especially https://github.com/j3-fortran/fortran_proposals/issues/108#issuecomment-564182953. https://github.com/j3-fortran/fortran_proposals/issues/108#issuecomment-564370588

So if the matter of some guidelines for counterarguments can be addressed better under CoC of this site and if some consideration can be extended to what I suggest here, it will help.

[milancurcic]

Non-technical arguments are OK, and I don't think they should be dismissed or discouraged (or dictated by the CoC). However, technical arguments go a long way to help a proposal. This isn't a competition in which the strongest technical argument wins and gets adopted in the standard. This is about trying to persuade the rest of the community (and hopefully committee members) that a change is needed. The original post was a one-liner with almost nothing to give, this is why I asked for some technical arguments so we can have a real discussion and weigh the pros and cons.

When each of us propose a change to the language, we need to do the homework and show (or convincingly speculate) that the benefits will outweigh the cost, not the other way around.

[klausler]

I fail to see anything technical in the arguments posted counter to the original post here: #108 (comment), especially #108 (comment).

Statements of fact qualify as technical points, whether they're required to be so to constitute counterarguments to non-technical complaints or not. Specifically, from my comment to which you linked above: fixed-form source is still in use and is easy to support. The first claim is obviously true, and I've documented why the second claim holds with data.

[aradi]

I'd like to note that a language version keyword as discussed in #83 could also allow for giving up compatibility with fixed-form source. Whenever the programmer specifies a language version newer than a given date (e.g. 202Y), the processor could refuse to compile the module, if it is in fixed-form. Nevertheless, people could still compile and develop their legacy codes, they just would not be allowed to use any new constructs (and default behaviors) introduced in Fortran 202Y or later without converting to free-form.

[sblionel]

The typical way of handling this is a directive that looks like a whole-line comment. You're already familiar with these (!DIR$, !$OMP, etc.), as well as shell scripts. Many compilers already support !DIR$ FREEFORM or similar.

I don't recall if J3 has ever taken up the idea of directives in Fortran source, rather than preprocessing.

[certik]

@sblionel when it comes to adding new features to Fortran, do we still need to consider how they will work with fixed-form? Is it acceptable to simply say that for new features, such as #11, we do not need to consider fixed-form? I see lots of positives of that, but I don't know if there is any downside.

[sblionel]

Yes, we still need to consider fixed-form. It is still part of the language. And despite my entreaties to the contrary, people still write new code in fixed-form.

[certik]

Yes, we still need to consider fixed-form. It is still part of the language. And despite my entreaties to the contrary, people still write new code in fixed-form.

What would be the reasons why people have to write fixed-form? Is it just a lack of a tool that would reliably do the conversion, or is there another reason?

[sblionel]

"have to"? No. But it's what they're used to and that's what they do.

[gronki]

That's what I mentioned in some other posts. We all know they do. But they shouldn't. How do we force them to stop? I think not having nice features would be a good motivation.

In Linux world, people are unhappy with changes all the time, but then the new solution is forced upon users and everyone just adjusts. I think standard is not enforcing enough to discourage bad coding such as fixed form.

czw., 12 gru 2019, 16:51 użytkownik Steve Lionel notifications@github.com napisał:

"have to"? No. But it's what they're used to and that's what they do.

— 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/108?email_source=notifications&email_token=AC4NA3IWDKISK7ELR5MJS4LQYJMX7A5CNFSM4JYYZB4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXDKSY#issuecomment-565065035, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3LALQRY42Y2LZSOM4LQYJMX7ANCNFSM4JYYZB4A .

[certik]

When I discussed this with quite a few people, it seems that a reasonable compromise is to support fixed-form for current codes, but not adding new features to it, e.g., if you want to use enumerators, you would first need to convert your fixed-form to free form. So that we do not need to discuss fixed-form restrictions when designing a new feature.

[certik]

@FortranFan wrote:

May I please see some consistent adherence and application of this?

I just created a separate issue #109 to discuss how to communicate, please let's move that discussion there, and only discuss fixed-form here in this issue.

[FortranFan]

@certik wrote:

When I discussed this with quite a few people, it seems that a reasonable compromise is to support fixed-form for current codes, but not adding new features to it, e.g., if you want to use enumerators, you would first need to convert your fixed-form to free form. So that we do not need to discuss fixed-form restrictions when designing a new feature.

Ergo the proposal in the original post.

Within the parameters of the current system toward the Fortran standard, the compromise of "support fixed-form for current codes, but not adding new features to it" only appears feasible if fixed-form is marked as DELETED in the official standard.

Deleting fixed-form from the standard will not preclude any existing or new compiler from supporting fixed-form: one can look at the support of already deleted features in most of the current compilers. But the further development of the standard is freed up from the confines of fixed-form.

As indicated in https://github.com/j3-fortran/fortran_proposals/issues/108#issuecomment-565061961 with the committee approach of which I've been acutely aware, my worry all along has been even the features toward Fortran 202Y - say GENERICS and perhaps exception handling or one or two others if they get considered - would all need to be compatible in their design with fixed-form source. My experience remains the need to remain compatible with fixed-form has adversely impacts VERBOSITY in Fortran.

Unless the compromise indicated by @certik can be pursued with some urgency, there remains the risk of suboptimal designs of new features in Fortran due to support for fixed-form source and that is not at all a healthy and encouraging prospect for developers like @jacobwilliams who are among the few persevering with Fortran.

[klausler]

That's what I mentioned in some other posts. We all know they do. But they shouldn't. How do we force them to stop? I think not having nice features would be a good motivation. In Linux world, people are unhappy with changes all the time, but then the new solution is forced upon users and everyone just adjusts. I think standard is not enforcing enough to discourage bad coding such as fixed form.

Why in the world would anybody want to force fixed-form users to stop using fixed-form?

[gronki]

For the reasons clearly listed above that I am not going to repeat. :)

czw., 12 gru 2019 o 18:08 Peter Klausler notifications@github.com napisał(a):

That's what I mentioned in some other posts. We all know they do. But they shouldn't. How do we force them to stop? I think not having nice features would be a good motivation. In Linux world, people are unhappy with changes all the time, but then the new solution is forced upon users and everyone just adjusts. I think standard is not enforcing enough to discourage bad coding such as fixed form.

Why in the world would anybody want to force fixed-form users to stop using fixed-form?

— 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/108?email_source=notifications&email_token=AC4NA3LXI562YJXSIZ4QZPLQYJV2DA5CNFSM4JYYZB4KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEGXLG7Q#issuecomment-565097342, or unsubscribe https://github.com/notifications/unsubscribe-auth/AC4NA3JJWJQOQO4WPKUMDODQYJV2DANCNFSM4JYYZB4A .

[klausler]

For the reasons clearly listed above that I am not going to repeat. :)

The only serious point that was raised was that fixed-form makes it harder to add a feature to the language that would change parsing of keyword statements like END to be context-dependent. Such bad ideas should be hard to add to the language, so that's a reason to retain fixed-form.

[certik]

@klausler let's discuss the actual argument in #11 more with regards to fixed-form. One proposed syntax is:

enum some_type
    enumerator a, b, c, d, end, e, endenum, f
end enum

and the reason why we cannot just have

enum some_type
    a, b, c, d, end, e, endenum, f
end enum

is that end and endenum can be confused with end enum when parsing (especially if the optional space is omitted). I think that's probably true, but I think the modern standard could be modified to require end if, end function, end enum to be always written with a space in between. And in that case, I don't know if there is still an ambiguity in free-form (more ambiguity than there already is with regards to end -- it is already context dependent).

[klausler]

ENUM SOME_TYPE
  CONTINUE
  STOP
  END
  CONTAINS
  PRIVATE
  SAVE
END ENUM

Statement classification is already difficult and bug-prone in Fortran. This feature makes it worse -- a bare END statement may no longer be an END statement, &c.

[certik]

@klausler I think you are right. This is the main argument, and that has nothing to do with fixed-form.

I propose that fixed-form arguments should not even enter the discussion, and should not be mentioned in the proposal for #11. Rather, the argument that you just made about the end ambiguity is the main argument.

[FortranFan]

@certik wrote:

@FortranFan's main point is valid, that fixed form was used as an argument why something cannot be done in 19/19-249.txt. If fixed form didn't have to be considered, perhaps the ENUMERATOR keyword would still be necessary for other reasons, as @klausler indicated, but perhaps not. However let's discuss that at #11.

@FortranFan please try hard to stick on topic and just discuss technical arguments in issues, otherwise every issue becomes buried and people stop participating here. If you want to discuss your wider points, just open a new issue and link it. But for already open issues that somebody opened to discuss a particular topic, please try not to derail the discussion.

In https://github.com/j3-fortran/fortran_proposals/issues/92#issuecomment-569315654, @klausler wrote:

Attributes before the FUNCTION and SUBROUTINE keyword are how things are done today, like it or not. It was a bad design and it restricted at least one syntactic possibility (one can write CHARACTER*7 or CHARACTER(LEN=NAMEDCONSTANT) but not CHARACTER*NAMEDCONSTANT, and that's due at least in part to the ambiguity that would introduce in CHARACTER*IMPUREFUNCTIONFOO()). But that ship has sailed; adding a redundant ATTRIBUTES(...) syntax would not enable any new capability.

CHARACTER*NAMEDCONSTANT does not conform to the standard but CHARACTER(NAMEDCONSTANT) does.

And a function declaration such as CHARACTER(NAMEDCONSTANT)IMPUREELEMENTALFUNCTIONFOO() is standard-conforming in fixed-form source (assuming other requirements are satisfied) but obviously not in free-form source. Regardless I find it irrelevant to the discussion in #92 on FUNCTION or SUBROUTINE declarations.

Per section B.3.7 in 18-007r1 document toward Fortran 2018, fixed-form is obsolescent.

Bringing up a fixed-form code snippet to influence direction in any manner in a discussion to a new proposal (whatever "tier" it may be in, a convenience to a few mere mortal but persevering Fortranners or otherwise) which then also presents a risk to "derail the discussion" is exactly what I was trying to warn in my above https://github.com/j3-fortran/fortran_proposals/issues/108#issuecomment-564713380. It happens often enough, it's really harmful in that it too stops people from "participating" in Fortran. OP's proposal in this thread to "Delete fixed-form source format" remains a good suggestion for Fortran.

[sblionel]

The existence of fixed form can affect syntax chosen, but it has never, to my knowledge, actually blocked a feature from being developed. (19-249 is not an example of such.)

I'll also mention: "The program unit END statement shall not be continued. A statement whose initial line appears to be a program unit END statement shall not be continued." (6.3.3.5)

Fixed form isn't why the ENUMERATOR keyword exists, as @klausler points out. Fortran doesn't have reserved words and isn't going to start adding them.

I would be cautiously agreeable to the notion that new features be available in free-form only, where it made sense to do so. As I've mentioned before, there's a significant cost to deleting features from the language.

[jacobwilliams]

I would think the easiest way to ensure that new features only apply to free-form is to just delete fixed-form from the standard. Then you never have to worry about it again (let the vendors who want to worry about maintaining it for people who need to run unmodified 50 year old code...but the standard would be free to move forward unencumbered).

[klausler]

I would think the easiest way to ensure that new features only apply to free-form is to just delete fixed-form from the standard. Then you never have to worry about it again (let the vendors who want to worry about maintaining it for people who need to run unmodified 50 year old code...but the standard would be free to move forward unencumbered).

Suppose for the sake of discussion that fixed source form were to be removed from the standard. Which Fortran compilers do you think would remove support for fixed source form?

[everythingfunctional]

I would think the easiest way to ensure that new features only apply to free-form is to just delete fixed-form from the standard. Then you never have to worry about it again (let the vendors who want to worry about maintaining it for people who need to run unmodified 50 year old code...but the standard would be free to move forward unencumbered).

Suppose for the sake of discussion that fixed source form were to be removed from the standard. Which Fortran compilers do you think would remove support for fixed source form?

My guess is the same number that have removed support for non-standards extensions (effectively zero?). But a guy can hope.

[FortranFan]

@sblionel wrote:

.. there's a significant cost to deleting features from the language.

I request any argument in terms of "cost" be treated as firmly off-topic in this repository.

No reliable and accurate data are available on any matter related to costs in Fortran. No honest or trustworthy discussion is then possible.

Moreover, any discussion regarding "cost" is meaningless without a full and fair consideration of the benefits.

When it comes to benefits though, I find the feedback on the value proposition and the benefit statements offered by many a persevering, "mere mortal" Fortranner either gets ignored or is rejected outright.

Under the circumstances, no "good faith" discussion can take place once cost and only cost makes it way into the discussion.

Yet if the cost argument is allowed to persist, then a honest position will be to note:

• features delayed are features denied, period. The resultant "opportunity costs" to Fortran and its well-being are then immeasurably high. Entire code-bases move permanently away from Fortran as a result

• features HALF-BAKED (e.g., several aspects introduced in Fortran 2003) are features ignored or misused. The resultant "opportunity costs" to Fortran and its well-being are again immeasurably high.

• features too VERBOSE are features abhorred by a large section of the computing community. The costs to Fortran's well-being again are immense.

With Fortran, all 3 of these points - delays, half-baked aspects, and verbosity - have been impacted to some extent or other by vendors' notions of backward compatibility, the continuing support of fixed-form source very much falls under this.

There is considerable evidence an inherently dishonest and unequal treatment of backward compatibility remains in Fortran, one just has to look at Annex B of the Fortran standard.

The aspect of the obsolescent-since-1997 fixed-form source facility is part and parcel of this biased treatment of backward compatibility in the language.

The cost argument is simply untenable, more than anything else it's one that always threatens to "derail a discussion".

[certik]

@FortranFan I agree with you that we should evaluate both the "cost" as well as the "opportunity cost". (Although I think it's very much on-topic here to discuss these costs.)

So I think @sblionel is correct that "there's a significant cost to deleting features from the language". But I also believe there is a significant opportunity cost of not deleting features from the language, and we have to weigh both.

[klausler]

At what point on a language change's path from concept to formal description to standardization to implementation should cost become relevant?

@sblionel wrote:

.. there's a significant cost to deleting features from the language.

I request any argument in terms of "cost" be treated as firmly off-topic in this repository.

No reliable and accurate data are available on any matter related to costs in Fortran. No honest or trustworthy discussion is then possible.

Moreover, any discussion regarding "cost" is meaningless without a full and fair consideration of the benefits.

When it comes to benefits though, I find the feedback on the value proposition and the benefit statements offered by many a persevering, "mere mortal" Fortranner either gets ignored or is rejected outright.

Under the circumstances, no "good faith" discussion can take place once cost and only cost makes it way into the discussion.

Yet if the cost argument is allowed to persist, then a honest position will be to note:

• features delayed are features denied, period. The resultant "opportunity costs" to Fortran and its well-being are then immeasurably high. Entire code-bases move permanently away from Fortran as a result
• features HALF-BAKED (e.g., several aspects introduced in Fortran 2003) are features ignored or misused. The resultant "opportunity costs" to Fortran and its well-being are again immeasurably high.
• features too VERBOSE are features abhorred by a large section of the computing community. The costs to Fortran's well-being again are immense.

With Fortran, all 3 of these points - delays, half-baked aspects, and verbosity - have been impacted to some extent or other by vendors' notions of backward compatibility, the continuing support of fixed-form source very much falls under this.

There is considerable evidence an inherently dishonest and unequal treatment of backward compatibility remains in Fortran, one just has to look at Annex B of the Fortran standard.

The aspect of the obsolescent-since-1997 fixed-form source facility is part and parcel of this biased treatment of backward compatibility in the language.

The cost argument is simply untenable, more than anything else it's one that always threatens to "derail a discussion".

[FortranFan]

See this comment in #221.

In reply, @everythingfunctional writes

.. fixed-form is obsolescent (IMO) it would be reasonable for that feature not to be available in fixed form

My view is as follows:

Obsolescent is simply a label per the standard, it has no teeth. A feature marked obsolescent remains effectively "first class," meaning all new features need to integrate with it. As long as a feature is NOT deleted from the standard, its semantic and syntactical implications need to be fully taken into account.

Fixed-form has been obsolescent since Fortran 95, published nearly 25 years ago. It will continue to hinder options for newer revisions as long as it is not deleted. As recently as the last standard meeting, the selection for conditional expressions was predicated on support for fixed-form source; the final form that was chosen was low in popularity at the online forum.

[certik]

It should be deleted from the standard.

But what should compilers do? They have to support it. I think the natural way is to not support some newer features that will be available in free form only.

[sblionel]

I disagree with @FortranFan - obsolescent features are NOT "first-class", they generate diagnostics when standards checking is enabled (some compilers by default), they are in small type in the standard and tend to not be taught in textbooks.

In practical terms, deleting fixed-form source would have no effect beyond declaring it obsolescent. Compilers will continue to support it. If deleted, compiler developers will lose guidance for how to process fixed-form source.