A new category of outmoded features: Retired

[FortranFan]

Background

Fortran standard revisions starting Fortran 90 include 2 categories of "outmoded features": Deleted and Obsolescent.

With Deleted features, the standard makes their status clear, such features are simply "not included" starting with the revision the features get placed in that category.

The Obsolescent category however is indistinct: the features in this category remain included in the standard albeit with a smaller type size; additionally, newer feature additions to the standard need to integrate with them. A revealing example of this issue is fixed-form source, which has been obsolescent since the Fortran 95 revision that was published nearly 25 years ago, and the feature set under development as part of "Conditional Expressions" in Fortran 202X wherein the proposed and voted-upon solution was predicated by the need to work with both source forms.

And note the standard states, "A future revision of this part of ISO/IEC 1539 might delete an obsolescent feature if its use has become insignificant." Note the operative phrase, "if its use has become insignificant." There is no objective method amenable to anyone including the Fortran standard body to ascertain when the use of obsolescent feature has become insignificant. Consider implicit mapping which is not yet obsolescent: one is hard-pressed to point to a single codebase among the vast number of known and now increasingly public codebases that truly and purposefully employs the implicit mapping facility in the standard. Yet the refrain remains there are significant investments with such a feature remaining in existing software and thus the feature cannot be deleted.

The situation then is the near impossibility of deleting an obsolescent feature when the continued presence and support of outmoded features hinders the advancement of the language and hurts its image and the goodwill around it.

Proposal

Introduce a new category termed Retired to unburden future revisions of the standard. It is expected the standard body and the Community shall collaborate to determine the attributes of features marked as Retired. The initial expectation with Retired features is

1. they are those that were first marked as Obsolescent,
2. once a feature is retired in a given standard revision, new feature introductions in that revision and subsequent revisions shall not be required to integrate with the retired feature with the possibility being also of the retired features being incompatible with subsequent new features,
3. where a standard-conforming processor shall be asked to have the ability to detect and report them as such i.e., to the extent it is reasonable for a processor to do so within the rules and constraints in the standard; this is the same as included in the current standard with obsolescent features,
4. the retired features are identified in the standard by a relegation of all the details pertaining to its semantics and syntax to a certain location such as Annex xx (xx depending on the standard revision document),
5. the standard text on the retired features being considered as frozen, meaning no further edits or enhancements to the text of the standard shall be made to such features.
6. they are the ones that are on the slate for consideration toward eventual deletion from the standard. That is, the order can be an outmoded feature goes to being Obsolescent first, then Retired, followed by Deleted.

[rouson]

I like this idea. It would be interesting to hear the Editor's perspective on the feasibility of this proposal. For features that have a section of the standard devoted to them, it would be straightforward to move that section to an annex. What about when the feature interact with another feature in some way that needs to be mentioned in a different section? If these additional references to the retired feature are also moved to the annex, it might make parts of the standard tricky to use.

[FortranFan]

@rouson writes Aug. 28, 2021, 4:20 PM EDT:

I like this idea. It would be interesting to hear the Editor's perspective on the feasibility of this proposal. For features that have a section of the standard devoted to them, it would be straightforward to move that section to an annex. What about when the feature interact with another feature in some way that needs to be mentioned in a different section? If these additional references to the retired feature are also moved to the annex, it might make parts of the standard tricky to use.

Glad to read, "I like this idea". I appreciate your comments and agree entirely with the concerns.

But I think things are coming to a head with Fortran i.e., the modern incarnation starting with the ISO/IEC 1539 : 1990 revision.

Modern Fortran is arriving (or has arrived) at the proverbial "fork in the road": to paraphrase Frost, does Fortran now take the easy path, one that is highly comforting to and strongly preferred by the dominant majority among the standard bearers and which addresses mostly some immediate needs only at considerable harm to longer-term innovation and advancement; or, embrace the harder path (fork) that requires more effort and attention to vision and be brave and which can strengthen the language, its advancement and its application toward the bigger challenges facing humanity whether it be climate change, energy demands, pandemics, etc.

Few things in life are easy; if they were, there would be no need for computers or computing generally. Humanity could have made do with the digits on their hands, or having invented abacus, been content with it.

Now, consider ANSI X3.9 1978, ISO 1539-1980 document that pursued full language and a subset language demarcations: "FORTRAN 77 is a revision of American National Standard FORTRAN, ANSI X3.9-1966. It describes two levels of the FORTRAN language, referred to as FORTRAN and Subset FORTRAN. FORTRAN is the full language and appears on the righthand pages; Subset FORTRAN is a subset of the full language and appears on the lefthand pages."

Imagine the effort on the writers of 1539-1980 to layout the subset language on the lefthand pages and the FULL language on the righthand pages!

The proposal here is not specifically demanding the same approaches as pursued previously be adopted exactly, not by any means. The suggestion here is mostly to be inspired. When there were needs, those who preceded in Fortran's journey did the hard yards. There is so much an Editor (or an Editorial Board) can do now to achieve more with lesser effort with modern document management tools and collaborative approaches and crowdsourcing. If there is a will, there will be a way.

Rather than preserve the status quo, can something be done with the standard document itself to move beyond aspects that have long been obsolescent but which yet need to be taken into account in future directions?