- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The week before the recent WG5 meeting in Tokyo, previous WG5 convenor John Reid, and I, gave talks at the University of Tokyo. John spoke about coarrays and I spoke about Fortran 2018. (We met with a translator beforehand - we would have to pause frequently and wait for the translator to convert what we said to Japanese. It was interesting.)
I have attached my presentation. Feel free to ask me any questions about it, (There are speaker notes, which may be indicated by an icon in the upper left corner of the slide.)
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing this informative preview. Interesting (and possibly disappointing) to see that labeled DO statements will be in the obsolescent category in future. Would they ever be not supported or deleted? Many of my Fortran codes with nested loops rely on EXIT and CYCLE statements that direct the code to a labeled DO thereby avoiding the much scorned GOTO while at the same time allowing the code to jump across to a different location.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Features may get deleted from the standard, but compilers will continue to support them. Many features have already been deleted (Arithmetic IF, assigned GOTO, more - see here) but are still supported by all major compilers. Compiler vendors won't actually remove support for deleted features - at most they'll issue optional or suppressable warnings if you use them. Personally, I am not in favor of deleting features from the standard as this removes any discussion of how they work with other features.
You can use named DO loops instead of numerical labels.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve Lionel (Ret.) (Blackbelt) wrote:You can use named DO loops instead of numerical labels.
Thanks for clarifying. I think I was confusing "named" loops (MYLOOP: do ... end do MYLOOP) with "labeled" loops (do 1 i = 1,n ... 1 continue). I don't use labeled loops for several years now except in that many irreplaceable legacy codes have them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The "arithmetic IF" has been introduced in the latest version of the C++ language.
Any change that Fortran gurus will resurrect it ?
Regards
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Steve,
Regarding Page 9 of your presentation:
Why doesn't (didn't) the CFI_establish, CFI_allocate, CFI_deallocate, CFI_... take a reference argument.
Or why doesn't CFT_CDESC_T(0) construct a CFT_cdesc_t object? (I suspect CFT_CDESC_T is a macro)
I know that the C/C++ side is not your bailywig but why the seemingly unnecessary type casting?
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Page 11
>>A Fortran procedure with a CONTIGUOUS dummy argument must be able to handle a C descriptor for a non-contiguous array
Then wouldn't this imply that CONTIGUOUS is invalid (or at least meaningless) for bind(C) procedures?
.OR.
Does this imply that Fortran now behaves like the long awaited "Please determine if the dummy is contiguous or not and take the appropriate optimized code path".
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Page 20:
Sad to see EQUIVALENC obsoleted. This will (may) require source changes to insert ASSOCIATE in the code section or => on the USE.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Luigi R. wrote:The "arithmetic IF" has been introduced in the latest version of the C++ language.
Any change that Fortran gurus will resurrect it ?
Regards
Arithmetic IF feature that got deleted in Fortran 2018 involves branching based on statement labels: what in "latest" C++ you think is equivalent to this?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Luigi: No, Arithmetic IF is not coming back. You may have noticed that the standard is gradually backing away from numeric statement labels and GOTO. The sorts of things arithmetic IF was used for can often be handled by SELECT CASE. I will note that conditional expressions, a proposal for Fortran 202X, might be an alternative in some cases.
Jim: Slide 9 - You are correct that CFI_CDESC_T is a macro that declares an untyped struct. You are also correct that I am not strong in C/C++, but if I have it right, the issue is that CFI_CDESC_T can create different length structs depending on the rank, so one couldn't declare it to be a CFI_cdesc_t. The standard says, in a note:
The CFI_CDESC_T macro provides the memory for a C descriptor. The address of an entity declared
using the macro is not usable as an actual argument corresponding to a formal parameter of type CFI_-
cdesc_t * without an explicit cast.
Slide 11 - In a Fortran-Fortran call, the caller is required to pass a contiguous actual argument if the dummy is CONTIGUOUS, which can mean copy-in/copy-out. The standard doesn't want to put requirements on C compilers, so for a Fortran interoperable procedure with a CONTIGUOUS argument that is passed by C descriptor, it is up to the called Fortran routine to do whatever is needed if what comes in is not contiguous. Yes, this could mean different code paths, theoretically, but I'd expect the typical result would be to make a contiguous copy.
There's a similar issue with ALLOCATABLE, INTENT(OUT). Normally the check and deallocate is done on entry to a Fortran routine, but if one is calling a C routine with such a dummy (passed by C descriptor), the Fortran caller has to do the check/deallocate before calling. Note here that "C routine" can also be a Fortran procedure with BIND(C), in which case the check is done twice (but obviously any necessary deallocate is done just once.)
Slide 20 - No comment about COMMON? There were lots of arguments about EQUIVALENCE, but everyone agreed it was a bad programming practice that led to difficult-to-diagnose errors. Of course, you can continue using both of these since they're not actually going away, but if you ask for standards checking you will get warnings.
The notion with EQUIVALENCE was more about using TRANSFER - I'm not sure what ASSOCIATE gets you in this context. The two main uses I see of EQUIVALENCE are 1) space saving (overlays), and 2) type-casting. Space saving is error prone and really unnecessary nowadays, and there are less error-prone ways of doing type-casting.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
A 3-way operator "<=>" has been defined in C++20.
One can find description at "https://en.cppreference.com/w/cpp/language/operator_comparison" and other web-sites.
About EQUIVALENCE I completely agree with Jim Dempsey. What is a different way to tell the compiler that two variables share the same memory location ? C++ has a "union" construction.
It seems that people managing the fortran standard are willing to change the language into something for students and not for professional programmers.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing Steve, very informative.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In addition to effective UNION
A lot of old (Legacy), large, applications use functions and subroutines from many source libraries. Discarding EQUIVALENCE will require editing and potential breaking of these libraries. There is a difference in obsoleting a language feature and having the compiler nag you to use an alternative.
>>It seems that people managing the fortran standard are willing to change the language into something for students and not for professional programmers.
Steve, were the pro and con arguing parties divided between academia and well seasoned scientists&engineers? (theoreticians and practitioners).
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
It's a balance, really. Both academics and engineers contribute and argue their cases. I would say it's more on the side of application developers, as it should be. I absolutely disagree that the language is being aimed at students. The general philosophy is to accelerate application development in areas where Fortran is strong, and to discourage usages that have been problematic and error-prone. Recently the committee has added members from engineering disciplines, which is good, though most tend to be from government labs (NASA, DOE, etc.) Vendors are also well-represented, generally by people from respective support teams, giving good insight into what their users want (and what gets them into trouble.)
The lack of UNION in derived types is, sadly, a serious hole for real-world applications, but it would not be "type-safe", which the language is aiming towards. There are ways around it, of course. I haven't seen a recent proposal for unions or variant types, and this did not show up much if at all in the user survey.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Luigi R. wrote:A 3-way operator "<=>" has been defined in C++20.
One can find description at "https://en.cppreference.com/w/cpp/language/operator_comparison" and other web-sites.
About EQUIVALENCE I completely agree with Jim Dempsey. What is a different way to tell the compiler that two variables share the same memory location ? C++ has a "union" construction.
It seems that people managing the fortran standard are willing to change the language into something for students and not for professional programmers.
I agree. This would be disaster for my legacy code.
I. Konuk
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for sharing.
Is John Reid's presentation about coarrays also available?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I will ask him.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>The lack of UNION in derived types is, sadly, a serious hole for real-world applications, but it would not be "type-safe", which the language is aiming towards. There are ways around it, of course. I haven't seen a recent proposal for unions or variant types, and this did not show up much if at all in the user survey.
I currently use the non-standard but Intel supported UNION to read and write data files where the type is not known until the read or write is well underway. In one case it is for data compression/decompression:
... union map real(8) :: valREAL8 end map map real(4) :: valREAL4 end map map integer(8) :: valINT8 end map map integer(4) :: valINT4 end map map integer(2) :: valINT2 end map map integer(1) :: valINT1 end map map integer(1) :: ArrayINT1(8) end map map character(8) :: Name end map end union ...
I find it unfortunate that UNION is not officially supported. Without UNION, a significant amount of Fortran->C->Fortran code would have to be implemented. A lot of unnecessary work IMHO.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Yes, this is an example of a "variant type".
STRUCTURE/RECORD/UNION/MAP were created for VAX FORTRAN in 1988, when it was unclear when the next standard would be finalized (first called Fortran 88, then Fortran 8X, and eventually Fortran 90.) I don't know why unions were rejected, but as an example, the feature where writing a derived type using formatted I/O would be untenable in the presence of unions.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>> I don't know why unions were rejected, but as an example, the feature where writing a derived type using formatted I/O would be untenable in the presence of unions.
I don't buy that argument.
Formatted write of derived type requires the user to write a User-Defined Derived-Type I/O routine. The content of the derived type (presumably) would contain an indicator specifying the choice of (or lack thereof) the UNION entity. If (when) there is a "don't care" situation, a suitable choice can be made such that the entire set of bits within the union are written/read as-is. In the above valINT8 could have been chosen. IOW your choice would be a blob that can be formatted written as text then later read as text without disturbing the contents whatever they be.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
No, it doesn't require UDDTIO, unless the derived type has pointer or allocatable components.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page