I have a copy of the Draft Fortran 2023 standard dated 22nd April 2022. If that’s not the latest available, what is?
It seems to be the latest draft available. There are also a few “Editor’s report for 22-007r1” and “Editorial Corrections for 22-007r1” text files.
I think the final corrections will be included only into the ISO document.
There will eventually be a new 007 document that the committee will use for reference against F2023. The official standard is copyrighted by ISO and not freely available. (There is an effort, at least among SC22, to get ISO to relax its rules about availability of standard text. As it was explained to me, some country national bodies get most of their revenue from selling standards, so it may be difficult.)
8 Likes
The latest version was put online the 2023-02-20. Look in the directory J3 Fortran - Documents for year 2023
That is the latest draft, but not the final draft. Numerous comments were received during the DIS phase and a FDIS (Final Draft International Standard) is being produced. Not until the standard is published will there be a new “interpretation reference document”, though it may (and is likely to) be the same as the FDIS.
2 Likes
Latest version (13th June 2023):
2 Likes
Not final, due to ISO editor issues, but should be technically complete. There are some typos that will be fixed in the published version.
2 Likes
This is such a shame. The technical work on Fortran 202Y (will it still be 2023?) stopped a long time ago, for nearly two years now, the administrative stuff on the document continues with some typos still pending!
In the time it takes for a piddly little standard revision for Fortran, entire new languages spring up with functioning processors and ecosystems with more and fully-developed features for scientific and technical computing. This is terrible for computational scientists and engineers and their managers and sponsors who have made a lot of investment in Fortran.
WG5 and J3 need to really develop a vision that includes the standard revision workflow which is made entirely open: an open standard.
Then the current Editor, Malcolm Cohen, must be forced to crowd-source the editorial work on an open platform, whatever it be. An Editor like Cohen must be running regular tutorials and really working hard to teach online the young people who can replace him as an Editor. At a given time, WG5 and J3, if they had vision, would line up at least five people globally who can take on the Editor;s mantle. On the contrary, I think the people are latching on to a wing a prayer, hoping (against hope) the current Editor can go on for ever, or at least until their time is up.
That is not how it should be.
It is precisely because the work of the Editor is so important that it must be really, really simplified and all the “knowledge” captured in a way that can be learned and picked up by many.
Additionally, all the tools and files and contents used to create the document - XX-007**.pdf - must all out in the open, reviewable by anyone and everyone who are interested, Instead, it would appear it is all private to the Editor currently. That is not good.
Fortran effectively has all its eggs in one basket, that of Malcolm Cohen. It is really a case where one person - who is not even online interacting directly with Fortran practitioners globally - has the most important responsibility that is managed privately but also has multiple other roles including that of the head of /DATA subgroup and in essence, someone who has a de facto veto power on most things. And who sees almost all user proposals as deserving of minus 100 points while being the lead or only developer of NAG Fortran that is really lagging behind in standard feature introductions.
Fortran has long been entirely hostage to the time and availability of one person.
The whole situation is extremely, extremely unhealthy for Fortran. WG5 and J3 should be working hard to change the fundamental dynamics around the workflow, but there is little to no evidence of any meaningful effort on this front.
4 Likes
@sblionel
I have a question about the Status column in the J3 directory https://j3-fortran.org/doc/year/23
Concerning BITS in F202Y, when I read:
23-175.txt | 2023-06-12 | 230 | Failed | Budiardja, Long | BITS Type for F202Y
does Failed mean that it won’t be included in F202Y or does it mean its specifications are not yet ready for discussion?
It means that J3 declined to add BITS to the US requests for F202Y. The specifications have been known since 2008, when it was in the draft for F2008 but was removed as it was felt the revision was too large (this happened shortly before I joined the committee, so I’m going on what I was told.)
BITS was proposed again by J3 for F2023, but with the note that an alternative would be to enhance and regularize the use of BOZ constants. WG5 chose the latter. (See Doctor Fortran in “We’re All BOZos on This Bus” - Doctor Fortran (stevelionel.com))
This time, the usefulness for BITS seemed lower, given the various bit intrinsics and enhancements to BOZ. The committee was apprehensive about adding an entirely new datatype to the language (and compilers) for something that people already do in Fortran without much difficulty. J3 voted 6-3 (2 abstained) against adding it to the US list. Theoretically, it could come back again in the next year, but I don’t think that will happen.
j3-fortran.org/doc/year/23/23-154r1.txt has the US list, all of which were accepted by WG5. Japan also submitted a proposal for “generic subroutines” - you can find it here, though it does not yet appear in the list of documents on the WG5 site (soon!).
I’m pleased to say that this morning I received word from the ISO Editorial Policy Manager that ISO will permit us to publish F2023 with our current font and font size choices; this is what I was referring to earlier. We have promised to move to ISO’s font specifications for the next revision.
5 Likes
A new FDIS has been submitted to ISO. There is an eight-week ballot period, and given other things, I expect publication in September or October. We received a waiver on the font and font size, which don’t conform to current ISO requirements, but we agreed to fix this for the next revision.
2 Likes
BIT type was not added not only because it was considered to be a large project, but because there was controversy whether the number of bits ought to be a kind parameter or a length parameter.
One can always create a kind parameter from a length parameter using derived type encapsulation, but there is no way to convert a kind parameter into a length parameter. One of the arguments for kind parameters is that it might help an optimizer to know that the parameter is a compile-time constant, but these days every competent processor can recognize compile-time constants.
@vsnyder are there accessible documents with the proposal and the possible syntaxes? I cannot really see how it would work with a KIND parameter (and if the size had to be known at compile-time, this would be a huge restriction).
There will be no better examples of
than what J3 and WG5 have done with the BITS proposal by @longb in the form of removing it altogether from consideration toward a standard revision yet again.
J3 and WG5 have only had since 2007 - 16 years!! - to iron out any issues, rather than indulge in the nonsensical length-type parameter vs kind-type parameter argument.
There is no evidence even of a proper discussion of the technical concerns and the possible consequences with the practice and whether it is of true relevance to the practitioners. What is missing is the evidence of truly attempting to work something out for the practitioners of Fortran, giving them something useful - and no, the intrinsic functions of Fortran 2008 etc. do not cut it. Especially by engaging with the broader technical community such as the readers of this forum and other such places, including those who have compiler experience such as the contributors to gfortran, LFortran, etc. and other languages to overcome any challenges with Fortran. All one can find are merely some opinions and a few words that helps avoid the effort toward Fortran 202Y.
Gosh, this is by no means “brain surgery”. By engaging closely with the Community, a facility can be developed that most will find useful. The attitude of the committees to do too little, too late is really hurting the language. Not having a built-in BITS type and a STRING type are classic examples of the lack of vision.
3 Likes
I do not have as long a history with Fortran, but I think your last point here rings true. As you mentioned above, entire new languages have sprung up, with large ecosystems around them, in the time it takes the Fortran standard to add the most incremental of improvements. In some cases, even inconsequential… sinpi, cospi - what are these? Literally who is asking for these? Is there some uber awesome assembly instruction that just does this super quickly but compilers are unable to recognize naive implementations and replace?
There are decades of examples of string types in computer programming languages. Fortran should have one. Some algorithms benefit from a bit type for 8x compacted storage or other uses. I do not understand the nuance that Fortran possesses which prevents it from adopting an implementation similar to any of numerous from lower, or higher, level languages.
3 Likes
My mistake - sarcasm is impossible to detect and pointless online; I am sorry. Yes, I knew they were the half cycle trig functions, but did not know that 1) they would be overly useful for anyone concerned with particular equations, or 2) they were part of any IEEE standard. To me, being part of the IEEE standard is probably the best argument for their inclusion in Fortran’s standard as well, since anyone working with sin(2pi*w/L) functions would already have a hand coded equivalent, likely in use for many years. The lack of half-cycle trig functions in Fortran is very unlikely to be the reason a new project avoids Fortran as its primary language.
This somewhat follows from the note about sinpi etc being part of IEEE. The hardware vendors aren’t going to be increasing scope and adding to an ISA for no reason - if there was an assembler instruction for this trig function, it would indicate to me that the operation is actually much more common than I thought, leading hardware vendors to implement something for it. In that case, Fortran should definitely seek to provide a function to users that easily maps to a capability provided by the CPU.
Also, I do not believe compiler vendors will special case anything. Based on other Fortran intrinsic functions I have examined, such as sum and gamma, the compiler’s generated code is no more performant or accurate than the naive implementation for “special/common” cases.
2 Likes
And this answers the sarcastic question. I can see that mocking all J3 committee decisions tend to be somehow trendy, but inquiring about the motivations before mocking would be a good idea.
Nobody said that, actually.
Right, but unfortunately nobody has to make such a claim for it to remain true.
The point was that there are features that programming language users want, Fortran users request and draft proposals for, and are repeatedly shot down or ignored. Things like asking for a string type are nothing brave, new, or revolutionary. They are asking for a semblance of parity with other “general purpose” programming languages, many examples of which have existed for for over 30 years. Instead of these types of things, which are actual blockers to increased usage (and therefore longevity, health, etc) of the language, we get small, much lower impact additions that take years upon years to be approved before years upon years more to be implemented.
If Fortran is not meant to be a general purpose programming language, that would be news to me. We would likely want to edit its Wikipedia entry, as well as submit notices to most other online resources giving history/explanation of “what is Fortran.”
1 Like
These are orthogonal topics. Minor and consensual additions like sinpi are nowhere near a reason why more important features are delayed/blocked/whatever.