(j3.2006) Pointless constraints

[Van Snyder]

On Wed, 2015-03-11 at 16:07 +0000, Bill Long wrote:

> What?s wrong with C_LOC (Array(1)) ?

That doesn't work for a rank-2 array.  Or rank-3.  Or....

As I pointed out at least twice during meeting 206, I had TWO include
files that did things to whole arrays.  A new requirement came along for
which C_LOC with a whole-array argument would have been the simplest
solution.  Those include files were used in 60 different contexts: one
for each of rank 1-15, one for each of rank 1-15 with another variable
of the same rank instead of a scalar, and independently for character or
not.  So I had to make 60 include files using

  C_LOC(A(lbound(a,1)))
  C_LOC(A(lbound(a,1),lbound(a,2)))
  ...
  C_LOC(A(lbound(a,1))(1:1))
  C_LOC(A(lbound(a,1),lbound(a,2))(1:1))
  ...

and then go change about 120 places where those include files were used,
to use the one with the correct rank.  SELECT RANK operating on a
specific-rank object would have allowed me to continue to use two
INCLUDE files (one each for character and non-character), instead of
needing SIXTY of them, and not change ANY of the INCLUDE statements,
instead of changing 120 or so.  Sure, TS 29113 makes SELECT RANK
irrelevant for this problem; it's only an illustration of a pervasive
(and perverse) habit of imposing pointless restrictions.  During the
last half century I've observed that my colleagues' imaginations are
unlimited.  Other pointless restrictions that I've already observed, and
upon which I've commented, eventually will get (or already have gotten)
into somebody's way; they provide no benefit -- only headaches.

Fortran isn't just used for brand-new programs that are written out of
thin air, used for a year or two, and thrown away.  I've worked on
programs that began with the original FORTRAN on the 704, and grew to
more than 6 million lines.

Pointless restrictions that we add because we think they will be
"helpful" frequently (usually) end up getting in the way and causing
significant expense.

....

> It sounds like this code has a spectacularly bad design.   I don?t
> think the problem here is the standard.

It's easy to criticize something of which you are entirely ignorant.

The "spectacularly bad design" is the failure of J3 to do ANYTHING to
address the problems of generic programming, and to include pointless
restrictions that eventually make other simple solutions impossible.

Perhaps our staff of two should simply throw away the "poorly designed"
1/3 million line code, for which development began before 1990, and
start over on a "superior" design?  If Bill can convince NASA to give us
twenty or thirty work years of funding, it sounds like a delicious
job-security project; we might be able to bring Bill in as a consultant
on "superior" design.

Here's the "spectacularly bad design:"

Two include files operated on entire arrays, which included deallocating
them.  They were used on arrays of ranks 1-15, of character and
non-character types.

Would a "superior" design have been to start with 60 identical include
files, twenty-some years ago (back then it would have been "only" 28),
on the remote chance that a problem whose best solution was to use C_LOC
(which didn't even exist in Fortran 90) would come along, and that C_LOC
(which didn't even exist in Fortran 90) wouldn't admit whole-array
arguments?  Or perhaps we should have written out code that ought to
have been identical in 120 or so places, and then watched it diverge
over the (twenty-five and counting) years of the code's useful lifetime?
GIVE ME A BREAK!

In J3's infinite wisdom, we have thrice rejected better solutions than
INCLUDE: parameterized modules, parameterized subprograms, and macros.
I'm stuck with INCLUDE, or significant duplication of code that was
expected, more than fifteen years ago, to remain identical -- and could
have remained identical, if only C_LOC had not originally pointlessly
prohibited array names as arguments.  Nobody has provided a reason, let
alone a good one, for this pointless restriction (or for the prohibition
against a polymorphic argument, which remains).  And we're still stuck
with the problem that the integration of PDT's and type-bound procedures
is woefully incomplete -- about which Richard Maine remarked roughly
fifteen years ago.

Now, in advance of any experience in its use, we've pointlessly crippled
the design of SELECT RANK.  Nobody provided a reason, let alone a good
one, for this pointless crippling.  Even though I presented a use case
for the pointlessly prohibited functionality, it remains prohibited.
Sure, TS 29113 solves the problem of C_LOC that would also be solved by
allowing specific-rank objects in SELECT RANK, but are we absolutely
certain that nobody will ever discover another case where it would be
useful?  I don't think so (unless we do macros).  SELECT RANK with a
fixed-rank object is, after all, a very simple and very limited macro.

I proposed a mechanism that could have been used for the problem that
would have been solved by allowing specific-rank objects in SELECT RANK
(and would have made FINDLOC useful), eleven years ago, in 04-195 -- but
that was rejected too.  Maybe it's a solution for all the problems that
would be solved by allowing specific-rank objects in SELECT RANK.  But
04-195 is still rejected.  It seems that solutions I propose to problems
I (and my colleagues) encounter have application to problems not yet
envisioned at the time of the proposal.

When I had to clean out a filing cabinet recently, I found my
correspondence with X3J3 concerning S8.99, S8.112, and S8.116 (in 1986,
007 was called S8).  Roughly half of what I asked for in Fortran 8x, and
for which X3J3 decided to go in a different direction (or nowhere), has
been found to be desirable, and incorporated into later standards.  Most
of the other half are related to still-unsolved problems.  One proposal
was to allow "arguments" on the INCLUDE line, which would have been
textually substituted -- a very simple macro facility, the first of four
proposals to attack the still-unaddressed problem of generic
programming.

> > Can we please stop trying to enforce our own programming-style
> > preferences using constraints, or at least not by constraints that
> > confer no benefit of consistency or correctness, and that will
> > eventually (long after I retire) be recognized as pointless, and
> > removed?