Small Fortran tools

[wspector]

@urbanjost

Yes. A huge opportunity missed for bad reasons. We maintained our own standard library so the vast majority of programmers had such routines available internally. It was maintained by the HPC and math sections and is diminished but still in use today. But we made a big push to get everyone using the PXF routines on the Crays in anticipation they would become a full part of the standard, along with the varying string length standard. None of it materialized on the other platforms and (oddly) we made our own PXF look-alikes for the other platforms almost exclusively calling their existing platform-specific extensions (so doing so themselves was quite plausible).

I wrote my own subset of the PXF library for personal use - almost all in C. I wrote test programs for all the calls, and found some bugs in the Cray implementation. Since I worked for Cray->SGI at the time, I was able to get them fixed. Later, when Intel started supporting it, I used my tests and found some bugs in their implementation - now long since fixed.

A big problem with PXF was that the spec was written with F77 in mind. This created obvious problems when data structures were needed. People didn’t like using PXFSTRUCTCREATE and associated handles. The other problem was the old ‘default integer’ issue on 32-bit systems with file and memory sizes and the like. Finally, for Fortran 90 users, a module should have been required. (My library has a ‘pxf_definitions’ module.)

I started re-writing my library a couple of years ago replacing as much C as I could with Fortran, but it remains an unfinished work. Either way, a few of the I/O calls can’t be implemented unless one has access to the compilers libraries - PXFFDOPEN is one. Eventually I’ll get it all working with gfortran.

[wspector]

@urbanjost

No, although for some reason I thought they had. Good candidates for procedures most times reinvented by users.

split and tokenize made it, but toupper, tolower and sort did not.

My own collection is in GPF; mostly in the M_strings module.

As a homage to toupper and tolower I added those filters on the Wiki page as well. I was trying not to overload it to much, but on second thought how can I leave those out?

It toupper and tolower were intrinsics and using the M_swap module the filter program is basically three executable lines plus a few lines of infrastructure, so it is hard to argue Fortran cannot handle character variables well.

Wholeheartedly agree that toupper and tolower should be Standard intrinsic functions. Same with sort. Seems like almost any significant Fortran program uses homegrown versions. I’ve suggested sort, along with grade, to several Committee members over the years to no avail. HPF had specs for sort_up/sort_down and grade_up/grade_down functions that could be used as a basis. But something simpler (e.g., without multiple dimensions and the DIM= complications) would be fine by me.

Lots of nice things in your GPF repository!

[everythingfunctional]

Not saying this will change minds in the to_upper/to_lower debate, but it’s definitely worth a watch and thinking about.

Plain Text - Dylan Beattie - NDC Copenhagen 2022

[jwmwalrus]

Looking at how other languages did it: Go used to have strings.Title, strings.ToUpper and strings.ToLower, until it introduced a cases package that allows you to select the case you want but for a particular language (with English as the fallback language).

(The strings.* functions are still available, since Go never removes anything but instead the tooling around the language forces you to move away from deprecated stuff)

Given the fact that the Fortran Standards tend to favor simplicity over quality of life, this approach is probably deemed too complicated —but it’s certainly doable with the aid of an ISO_FORTRAN_CHARS intrinsic module or something like that.

[rwmsu]

@jwmwalrus

Given the fact that the Fortran Standards tend to favor simplicity over quality of life

My own personal opinion is that the last few iterations of the Standard (and the Standards Committee) have been more focused on people writing libraries instead of standalone applications. I see your “simplicity over quality of life” as an example of this focus which is the only way I can explain some of the additions to the language that I don’t see anyone writing a standalone scientific application would ever use (but might find a use for when writing a library).

[wspector]

@everythingfunctional

Not saying this will change minds in the to_upper/to_lower debate, but it’s definitely worth a watch and thinking about.

It is a fun presentation. He didn’t include BAUDOT, the original 5-level Teletypes, BCD, EBCDIC, etc. The computer world was pretty much stuck with 6-bit character sets until the mid-1960s. Even in Fortran-77, when the character data type was specified, 6-bit character sets were still common - especially in the 60-bit CDC world. (The 36-bit Univac/Unisys systems too - though their Fortran 77 compiler was called ASCII Fortran and used nine bits per character. Their older compilers used 6-bit FIELDATA.)

But these days Fortran now has a precedent of ASCII-like characters for default character kind. (See section 7.4.4.1 in F2023.) Things like the ACHAR, IACHAR, and some comparison intrinsics are also defined in terms of ASCII. So for default character kind, defining to_lower and to_upper in terms of the ASCII subset seems like a no-brainer. If a specific implementation were to offer a UTF-8 or some other character kind, it might or might not be supported.

As to grading/sorting, the HPF spec also specified ASCII-like collating sequence. And see 7.4.4.4 of F2023.