[J3] For review: Official US position on features for F202X

[Van Snyder]

On Wed, 2019-03-06 at 14:45 -0500, Steve Lionel via J3 wrote:

> Attached is a draft of a paper listing all of the features that J3 has 
> approved for being on the F202X request list. This ends up being the US 
> National Body list for WG5 consideration in Tokyo. Please look it over 
> and let me know of any omissions or errors. I'll make this a WG5 paper 
> on Monday (assuming no further edits.) Special thanks to Bill Long for 
> assembling this!
> 
> Steve



What happened to short-circuit logical operators?  Straw vote on 18-152
recorded in 18-156 was 8-0-2.

What happened to syntax to specify that the target of a dummy pointer is
not to be changed?  Straw vote on 18-144 recorded in 18-156 was 7-0-3.

What happened to binary compatibility of C descriptors?  Straw vote
recorded in 18-156 (no paper) was 11-0-1.

Is it too late to follow up on "Allowing a specification section in
(some) constructs without forcing  use of BLOCK/END BLOCK seems useful.
No paper. Defer discussion to next meeting." See 18-156.  There was no
further discussion.

  US17. Syntax to specify an element or section of an array with
        arbitrary rank. (m218, 19-150, uc)

Also declare an array with arbitrary rank (19-152r1).

  US21. Typed enums. M217 paper 18-256r1 contains extensive discussion
of
        this feature along with a list of still-open questions.

Paper 18-114r1 from meeting 215 was a precursor to 18-256r1.  There were
two straw votes whether to proceed.  9-1-4 and 6-0-4.  18-256r1 is kind
of anemic by comparison.  The proposal, not a commentary on it, should
be the primary reference for the proposal.  The commentary should be
identified as a commentary, not the proposal.  See also 04-139r1, a more
complete proposal, which was not assigned to a subgroup at meeting 167,
and was rejected without discussion, straw vote, or motion and vote.

  US22. Conditional expressions. Permits conditional evaluation of parts
        of the logical expression in an IF statement.  M217 paper 18-274
        contains extensive discussion and alternatives for syntax and
        semantics. Generally supported, but needs more work.

Conditional expressions are NOT only for evaluating parts of expressions
in IF statements.  They're for evaluating parts of ANY expression,
anywhere, and calculating whether an actual argument is present.
Calculating whether an actual argument is present was an important part
of the 2004 proposal, and is an important part of the present proposal.
When conditional expressions were rejected in 2004, in order to
ameliorate the combinatorial-explosion problem with optional arguments,
we got instead the kludge that unallocated or disassociated actual
arguments corresponding to optional non-allocatable non-pointer dummy
arguments are considered to be absent.  Not doing the right thing in the
first place is a good way to make a mess.  Probably a permanent mess,
since after we finally "do it the right way" we probably can't delete
the kludge.

  US24. Generics / templates / macros / containers for generic
        programming. (m217: 18-281r1, uc (templates)), and (m218: 18-154
        (macros)).

Minutes of meeting 215 report that 18-112 (parameterized modules) should
be part of the proposal for generic programming.  18-112 also advocated
parameterized procedures, but /DATA discussed this at meeting 218 and
decided parameterized procedures would be subsumed by parameterized
modules and should not be pursued (19-141 uc).

What happened to "support for containers?"  Are we serious about doing a
good job, or any job at all, of support for containers, or are we aiming
for another half measure, or no support?

Concerning 18-110r1 and 18-123, meeting 215 minutes say "Containers
would not be the intrinsic thing, the intrinsic thing would be a means
to develop containers.  Committee to come up with enabling
technologies."  Straw vote on 18-142 was decisive (10-0-0).
"'Containers' as a feature will not be brought forward."  Committee has
not come up with enabling technologies.

19-120, 19-121, and 19-123 were marked "info" in the 218 web page.  They
were not assigned to any subgroup, read or discussed by any subgroup, or
mentioned in plenary.  I did not write them as an idle exercise.  I was
serious about proposals to support containers, as was announced in the
"Subject" line of 19-120, pursuant to "Committee to come up with
enabling technologies" in meting 215 minutes  I didn't write them with
the hope they would be swept under the rug without discussion.  As far
as I'm concered, they're still on the table for 219.

Containers need iterators, else the details of their representation must
be exposed in order to examine its contents (or a subset of them).
Coroutines need exactly the same infrastructure as iterators.  It's
silly to do iterators, and not do coroutines.  Coroutines also have
value for parallelism, since they are inherently thread safe.  A web
search for "coroutine" and "parallel" returned 267,000 hits (many on the
first page of results also mentioning "concurrent").   At least 50 other
languages directly support coroutines, and at least ten support
iterators (they're listed in 19-121).  It's difficult to use the "too
few other languages provide these" argument against iterators and
coroutines without thereafter needing to visit a chiropractor.

Containers need updaters to reduce maintenance costs.  Updaters are
called "setters" in python and some other languages.  They were called
"updaters" in POP-2, decades before python was a gleam in anybody's eye.
In 19-122r1, /JOR must have needed hernia repair after straining so hard
to invent reasons to reject 19-122 and 19-123:


      * The mechanism of accessors and updaters is not sufficient (in
        and of itself) to solve the problem of writing programs and
        modules that are type-agnostic at the time the programs or
        modules are written


There was no claim in 19-122 or 19-123 that updaters have anything to do
with type-agnostic programming.  Generic programming (and the subset
"containers") are not just type agnostic.  Generic programming is type-,
kind-, rank-, and representation-agnostic programming.  This irrelevant
item was just piling-on to make the case look more impressive.

Updaters help to reduce the cost of program modifications from
size-of-the-program to size-of-the-change.
I put several papers into the tutorials folder, that explained this
problem forty years ago.  In addition to the "updater" procedure, 19-122
and 19-123 also proposed an "Accessor," a way for an updater and
function to be combined with a persistent state, so that a program could
have several objects with the same structure but different persistent
state values (two sparse arrays, two queues, two stacks, two AVL
trees, ... for example).  This is not possible, or at least extremely
difficult, with only functions and updaters.  Their persistent states
would need to be SAVE variables.

Anybody who is serious about containers, generic programming, and
maintenance costs ought to re-read 19-120, 19-121, 19-122, and 19-123,
and read the papers in the tutorials folder by Ross, Parnas, Geschke and
Mitchell, and Popplestone and Burstall.  There's also a copy of my
correspondence with X3J3 about this topic in 1985.  It's really
disappointing that after 49 years nobody understands the
size-or-the-program vs. size-of-the-change problem, or at least doesn't
want to do anything serious about it.


      * Hiding the access and update mechanisms also hides the potential
        performance implications of using the accessors or  updaters.
        That is, what looks like a simple variable reference or indexed
        variable reference might invoke an almost unbounded  amount of
        code complexity.


This is exactly the silly argument that was advanced in 1986 at the
Albuquerque meeting, when I first proposed updaters.  YOU ABSOLUTELY
WANT THIS STUFF HIDDEN!  YOU DO NOT WANT THIS STUFF EXPOSED!  YOU DO NOT
WANT TO "SEE WHAT YOUR PROGRAM IS DOING" AT EVERY REFERENCE TO AN
ABSTRACTION!  Hoping that a human reader will find the "hot spots" in a
program by having the details of every abstraction exposed everywhere is
daft.  Exposing the details of every abstraction everywhere increases
lifetime ownership cost.  Requiring the syntax to expose them because
every different variety of object is referenced using a different syntax
magnifies lifetime ownership cost.

Use a profiler if you want to learn where your code is spending its
time!

Parnas's advice was precisely to hide the details inside procedures.
His paper (and the ones by Ross and by Geschke and Mitchell) sowed the
seeds of "Software Engineering."  The "information hiding" principle is
central.  Parnas proposed using procedures because every programming
language supports them.  Ross, Geschkle and Mitchell, and Popplestone
and Burstall, advocated language-design support for information hiding,
by moving toward uniform syntax.

Using procedures is good advice when developing a program in a language
with non-uniform syntax, but it isn't helpful for revising programs
wherein the advice was not assiduously followed during development
(which is almost always the case).  The problem with replacing intrinsic
abstractions such as arrays or derived-type objects with abstractions
implemented by procedures is that updating using a subroutine call has a
different syntax from updating using an updater in variable-definition
contexts.  This is precisely the reason that program changes have costs
proportional to the size of the program, not to the size of the change.
If you change the representation of an abstraction from an array or a
derived-type object to a container, you have to find all the places
where it (or a facet of it) is updated, and change them.  This cost is
almost always proportional to the size of the program, not the size of
the change.


      * The extended example and use cases do not demonstrate the use of
        the SECTION type, or motivate its need.


This sounds more like an excuse than a reason.  Please don't tell me
that members of J3 are so devoid of imagination that subclauses 2.3,
2.14, 2.15, and 2.16 in 19-123 provided no clues about the use of the
SECTION type.  The extended example in 19-123 was ONE example that was
not pretending to illustrate every facet of the proposal.  For those who
didn't figure it out by reading (or not reading) 19-123: To replace an
array with an updater and function, it is necessary to support section
notation for actual arguments.  Even to replace an array with a function
and subroutine (for updating) it is necessary to support section
notation for actual arguments.  Not having section notation for actual
arguments increases maintenance cost.  Not only is it necessary to find
every update and replace it with a subroutine call, but it is also
necessary to find every array-section reference and replace it with ...
something else -- because a function can't have an array section
designator as an actual argument.  Yeah, updaters are useful on their
own without SECTION, but SECTION greatly magnifies their scope of
applicability -- and the scope of applicability of functions.  I thought
this was so bleeding obvious it didn't need lengthy examples.  But, hey,
if you don't have a real case, stand on the rules.


      * Exposing the details of activation records, which it seems we
        do, does not seem like the proper level of abstraction for
        scientists and application programmers.


This is EXACTLY what is done by using derived types!  An activation
record definition, as described in 19-123, is a type definition, spelt
differently because declaring an object of the "type" also defines a
generic pair of function and updater procedures.  If it doesn't seem
like the proper level of abstraction, we ought to print derived type
facilities in \obs font, and eventually eliminate them.


      * The use of procedures and function references to get this
        capability does not seem too onerous a mechanism.


This might be fine advice when writing a progam, but it is rarely
followed assiduously, and it is absolutely unhelpful when updating one.
IT IS PRECISELY TOO ONEROUS A MECHANISM.  "After the program has been
deployed for N years, and the developers are not available, and
customers have new ambitions that induce new requirements, ask a new guy
to go find all the references and change them to function references,
and all the definitions and change them to subroutine calls."  It is one
of the reasons (probably the primary reason) for the size-of-the-program
vs. size-of-the-change cost difference.  READ THE PAPERS IN THE
TUTORIALS FOLDER!  Read some of the early software-engineering texts
that resulted from these papers.  Yourdan and Constantine comes to mind.


      * This feels very "un-Fortran-like". A mechanism that has been
        implemented in so few languages does not feel like a good
        candidate to add to Fortran.


This is terrible advice.  It says "Never learn anything from anybody
else!" and "Never invent anything new!"

Coarrays had not appeared in any non-Fortran languages before we added
them.

Updaters (frequently called "setters") are in many other languages,
including python, and have been for decades.  Several contributors to
Anton Shterenlikht's survey asked for "setters."

NOBODY ASKED TO DISCUSS 19-122 AND 19-123 WITH ME!  IT'S CL;EAR
THAT /JOR DIDN'T UNDERSTAND THEM, AND MAYBE DIDN'T WANT TO.  19-122r1
WAS DUMPED ON THE TABLE FOR VOTE WITHOUT ANY DISCUSSION WITH THE AUTHOR!
IT DIDN'T REFERENCE 19-123.  THANK YOU VERY MUCH FOR WASTING MY TIME!

As far as I'm concerned, 19-120, 19-121, 19-122, and 19-123 ought to be
on the table for genuine consideration at meeting 219.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.j3-fortran.org/pipermail/j3/attachments/20190306/6ac307a9/attachment-0001.html>