(j3.2006) "Rejected" proposal from 12-195

[Van Snyder]

On Thu, 2012-11-15 at 16:00 +0900, Malcolm Cohen wrote:

> If the paper was too superficial...

> Sure, just spam the committee with things they have already rejected.  I am sure 
> that will change everyone's mind.

Hmmm, I didn't provide enough detail, but more is unwelcome....

Here's a discussion of something from 12-195 that was evidently too
superficially described, but for which additional explanation was not
and evidently still is not welcome.  Nobody outside of subgroup had an
opportunity to consider it, and therefore "they" didn't reject it --
Malcolm did.

One of my colleagues has a contractual obligation to use a specific
module.  He has no funding to develop an alternative implementation of
its functionality, and has explicit instructions not to do so.

The only public identifier in the module is a type name.  In particular,
the names of the procedures bound to the type are not public.  He has
documentation of the components and type-bound procedures of the module.
He does not have the source code, or even a printed listing, and has no
funding to request that the provider make changes to it, or to pay for
recertification even if he had funding for changes.

He has a complicated decision process to decide which type-bound
procedures to use.

The procedures are invoked within his inner loop, but the decision
process is independent of the loop.  He'd like to hoist it out to
improve performance.

I suggested that the decision process compute an index, and his inner
loop use a case construct to invoke the type-bound procedures.  He
already thought of this.  A case selector still apparently imposed more
overhead than he thought it ought to.

He asked why he can't encode the decision as a procedure pointer or
procedure argument, which he has done in similar situations in other
parts of his program, where the procedure names were public (if by
"overhead" he means runtime instead of code bulk, maybe that's how he
measured the overhead of a case selector).

I explained that the syntax for procedure pointer assignment or
procedure actual arguments does not admit data-ref%binding-name.  He and
I became curious whether this syntactic irregularity is really
necessary.  I proposed in 12-195 that it is not necessary.  No
counter-argument to the proposition that this irregularity is
unnecessary has been forthcoming.

Regularizing this irregularity would require replacing <procedure-name>
and <proc-component-ref> in R740 and R1223 with <procedure-designator>
(i.e., simplifying two syntax rules) and adding a constraint on each of
them:

Cxxxx (Ryyyy) If <procedure-designator> is <data-ref>%<binding-name>,
<data-ref> shall not be polymorphic and <binding-name> shall not be
generic.

Regardless of the avenue by which I and my colleague arrived at the
observation of this tiny syntactic irregularity, and our conclusion that
it is not necessary, repairing it is a tiny project that seems to fit
well within the scope of M6 (and the edits are effectively done).

This won't be done in time to improve performance in my colleague's code
next week, but JPL has very long-lived codes -- some over fifty years
old -- that undergo continuous development.  Maybe someday, one of his
professional descendants could improve performance by exploiting this
tiny feature.