[J3] [EXTERNAL] Comments on 23-148

Sat Feb 25 03:46:56 UTC 2023

Hi Van,

Your paper was discussed in subgroup, though not at length due to the desire to finish the generics syntax paper.   Brad had taken a deeper look before arrival and did walk us through how some of it works.    We definitely agree that there are some useful ideas in there.  As with generics, my intent is to start first with some well-defined use cases and then work our way up to requirements and specs.  (And also as with generics, I’m still battling my own preconceived notions of how these things should look based upon my experience with C++ STL containers.)

I’ll also add that Malcolm expressed significant concerns that the remaining work for edits for the templating facility is sufficiently substantial that we won’t have time to make sufficient progress on these container features.    I certainly defer to his experience, but prior to that comment I had thought we were on a pretty good trajectory on that front.

And finally,  my paper on new generics features was hastily thrown together in part because I had conflicting guidance on whether generics subgroup even needed to submit such a paper.    So I was mostly just thinking of it as an opportunity to hare and wish that I had put a bit more rationale and used more careful terminology.

Cheers,

  *   Tom

From: J3 <j3-bounces at mailman.j3-fortran.org> on behalf of j3 <j3 at mailman.j3-fortran.org>
Reply-To: j3 <j3 at mailman.j3-fortran.org>
Date: Friday, February 24, 2023 at 5:17 PM
To: j3 <j3 at j3-fortran.org>
Cc: Van Snyder <van.snyder at sbcglobal.net>
Subject: [EXTERNAL] [J3] Comments on 23-148

23-148 proposes additional features for generics. The rationale is to "go a long way toward enabling user-defined containers." See 23-109 (Support for Containers), which is posed as a TS proposal but could be viewed as a 202Y feature proposal. The important concepts in that proposal are uniform syntax to reference what might be procedures or data objects in the container, and updaters (called setters in python).

23-109 references several papers that explain the advantages of uniform syntax. I argued for it at the 1986 Albuquerque meeting, but the sentiment "Fortran programmers want to see what their program is doing" won out. Of course, that is exactly what you DO NOT want, as explained by David Parnas in "On the criteria for dividing programs into modules" in December 1970 CACM. He pointed out that "seeing what your program is doing" results in the cost of a modification more likely being proportional to the size of the program than to the extent of the revision.

The specific controversy in 1986 was the notation to reference structure components. The percent sign had been introduced as a "place holder" because dot clearly had problems. The percent sign got stuck in place. I advocated for COMPONENT(OBJECT) instead of OBJECT%COMPONENT, because I had already used that syntax in Fortran IV processors that treated statement functions as macros, so that references to them were allowed in variable-definition contexts if their bodies were allowed therein. One could easily replace a reference to the statement function (i.e., macro) with a real function, but to use it in a variable definition context requires an updater procedure. References to and definitions of arrays and structures are just function/updater pairs that the processor knows how to write, inline, and optimize. This is all laid out in excruciating detail in 23-109.

Specific items in 23-148 included

- canonical mechanisms for looping/iterating over items in a container

See 23-107 (coroutines and iterators), for looping/iterating over anything, not just items in a container. 23-107 is posed as a TS proposal, but it could be viewed as a 202Y feature proposal.

-  enable other analogs of array features such as slices

See the parts of 23-109 that deal with the SECTION type. The SECTION type is necessary for uniform syntax, to allow an array to be replaced by a function and updater.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20230225/61693539/attachment-0003.htm>