- 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
- « Previous
-
- 1
- 2
- Next »
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
>>it doesn't require UDDTIO
OK then change requires to can use.
ergo a good argument becomes a weak argument.
Any argument against union in Fortran would equally apply to all other languages as well. For that matter, would call for elimination of type casting and the funky Fortran TRANSFER.
IMHO I think it would have been better to redefine the behavior of a READ/WRITE of a user defined type containing a UNION (and without UDDTIO). For example, using the first map declaration (requiring the programmer to declare the first map in a manner that can be safely written/read for all maps).
Note, due to the fact that a user defined type could potentially contain a pointer, the same argument could apply to justify either the elimination of pointer in user defined type and/or the elimination of using a user define type in an I/O statement (except for in UDDTIO). Absurd argument.
While I can see issue with pointer. I would also think there would be a similar issue with "allocatable, target". The same argument would apply.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
does not state allocatable are to be excluded from the UDT for I/O.
Jim Dempsey
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
jimdempseyatthecove (Blackbelt) wrote:>>it doesn't require UDDTIO
OK then change requires to can use.
ergo a good argument becomes a weak argument.
Any argument against union in Fortran would equally apply to all other languages as well. For that matter, would call for elimination of type casting and the funky Fortran TRANSFER. ..
Jim's points are very valid about UNION.
Now I'm quite a fan of deletions from the Fortran standard; my cost-benefit analysis (however skewed or simple-minded) informs me retention of many aspects in the language hurts Fortran considerably and after 30 years since the Fortran 90 revision, it's time to force a push toward modernity of legacy codes, so many of them are "dying" regardless of what Fortran continues to support and among the reasons for such a state where commercial considerations are paramount (and thus where professional programmers can work) is the reality for purse-string holders there are fewer and fewer to whom the 'baton' can be passed, particularly because the 'legacy' codes inevitably involve COMMON and EQUIVALENCE features, things that so many smart young engineers prefer to avoid. I will only be happy to see these features deleted and to be able to employ modern processors offering no support for them ('remainers' needn't worry for there will always be some compilers around to satisfy the legacy market), that way there can be continued and somewhat growing use of Fortran code toward scientific and technical computing, otherwise there will be FORTRAN code for some more time declining along the way until it becomes all obsolete.
Fortran standard has more than adequately addressed the use cases behind COMMON and it offers better and modern alternatives. But not so with the use case of a union type with EQUIVALENCE. There are valid needs for this in practical applications, especially in developing solutions requiring small, compact, and efficient user data types handling different types of 'variant' data. Given the language already had EQUIVALENCE - a limited union toward numeric types - it should have been INTUITIVELY OBVIOUS to build upon it (one shouldn't have to put together use cases for so many basic aspects of programming that are used so widely) and to offer better options for the future such as with an integrated MAP-UNION type of facility that fits with the rest of the language (i.e., it needn't necessarily be the DEC/VAX version but something that serves the needs). Alas, that ain't gonna happen any time soon.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
FWIW
A named COMMON is in effect a UNION with all other same named COMMON. The variable list and types of one same named COMMON need not be the same of a different COMMON of the same name ergo a union. While such use requires due-diligence of the programmer (no worse than other languages), an improved substitute for this might be desirable in the language. The UNION | MAP | END MAP | MAP | END MAP | ... | END UNION works, but my personal feeling it is a bit too verbose sitting on the standards committee (who have a background in C/C++ or other language with UNION), and as such may be objectionable ( enforcing "no resolution is better that one I don't like" attitude). The use of TRANSFER is not a suitable replacement due to a record may have many such differing fields in one context than in a different context. This makes use of TRANSFER unsuitable. While you could have multiple user defined types, and then use TRANSFER in effect to re-cast, TRANSFER cannot be use on the left hand side, nor does TRANSFER aid in indexing an array of objects of different sizes where UNION sizes the different variations at that of the largest. I therefor would desire the standards committee to give union serious consideration.
Jim Dempsey
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- « Previous
-
- 1
- 2
- Next »