On August 5th, @m_b_metcalf proposed to preserve a draft by the late Reinhard Bader about OOP in Fortran (link). Bader initially prepared his draft for Wikipedia now equally retained as a (Pandoc flavored) markdown file (link) and a pdf compiled with Pandoc/pdfLaTeX (link) on a platform independent to Wikipedia.
The project branched out because the use of markdown (as a markup lighter/more restrained than LaTeX) and Pandoc (as a moderator) offered to probe alternative compilations of a pdf. My picks were i) rst and rst2pdf, and ii) groff because ideally edits could focus on the .md file (and perhaps few times in a style template), but not in transient .tex, .rst, or .ms files created by Pandoc only if/when needed. Each of the three approaches tested revealed pros and cons (e.g., file size of the pdf, time of compilation). Here, prioritizing complete/non-distorted presentation of the content, the pair of Pandoc/pdfLaTeX eventually was considered the best one and hence is linked above.
I’m grateful to @m_b_metcalf for reviewing comments on an intermediate version of the pdfLaTeX generated pdf.
Addition: The printout to be considered «authoritative» for reading is the one compiled with pdfLaTeX, i.e. this one.
@certik Regarding the draft by Bader per se (at present state of the tools around), I would like to break some lines in the examples. Some comments are a bit long (which shows especially in the approach with groff, though its template used already adjusts for wider line lengths). I’m not aware about material to extend the content. An other thought is if I should add/intentionally not add a license tag on this; it is Bader’s work thus copyright (if it were a book, for at least additional 50 years post mortem in countries member of the Berne convention).
On the side about programs used to compile the pdf: there are couple of observations which lead to feature requests (e.g., \text{} of LaTeX is unknown to rst2pdf (link), but not to rst2html of docutils; I just note I didn’t check yet how does it work for sphinx). If these bumps (and couple of others either not yet figured out myself, or else filed) were resolved for the better, I would like to repeat the compilation with e.g., less numerous corrections sed introduces via the Makefile.
I’m reading through the paper (which gives some pretty good examples), but I came across a bit that I think is not quite right. The last sentence of 18.3
Disambiguation is possible due to the sufficiently different interfaces of the procedure arguments.
While the example is in fact valid, this explanation doesn’t quite get at the nuances of why it’s actually valid. From the standard, 15.4.3.4.5 Restrictions on generic declarations
Two dummy arguments are distinguishable if
one is a procedure and the other is a data object,
they are both data objects or known to be functions, and neither is TKR compatible with the other,
one has the ALLOCATABLE attribute and the other has the POINTER attribute and not the INTENT (IN) attribute, or
one is a function with nonzero rank and the other is not known to be a function.
So the reason that the example works isn’t because the procedure arguments have “sufficiently different interfaces”, it’s because they are functions whose results have different ranks. It’s mostly just worth noting because the extension to other examples may not work.