(j3.2006) Materials for 199

[Van Snyder]

On Wed, 2012-09-19 at 10:10 +0900, Malcolm Cohen wrote:
> I wrote:
> > They are already integrated.  Given the popularity of PDTs with vendors and
> > users, we should not be thinking of doing anything more with them at this 
> > stage in my opinion.
> 
> Van argued:
> >They are not integrated.
> 
> This is absolutely wrong....

I take Malcolm's point about the connection between PDTs and TBPs being
carefully spelt out in the standard.

What I'm getting at is that it is tedious, perhaps sometimes difficult,
to provide TBPs for all the kinds of intrinsic types provided by a
processor, even if they're only two kinds each of integer, real, and
complex.  Given that a processor can provide kinds not mandated by the
standard, it's impossible to do so automatically and portably.

What we had hoped to attack with macros or parameterized modules was to
make it easier to provide the spectrum of TBPs automatically, from one
base definition.  Of course, these projects both offered additional
functionality unrelated to PDTs or TBPs.

The simpler scheme I have in mind is to provide for definition of
parameterized or "abstract" procedures, which cannot be invoked
directly.  I hesitate to call them "procedure templates," to avoid
confusion.  A subprogram would be abstract if its definition included a
list of names, either (TBD) after the SUBROUTINE or FUNCTION keyword, or
after a new word in the prefix, say ABSTRACT(<parameter-name-list>).
Each of those names would behave very much like a PDT's kind type
parameter, and would be required to be declared within the subprogram as
an integer with the KIND attribute.  They could then be used in constant
expressions within the subprogram.  There are no new statements, and
especially no loops or conditionals as in the macro system.

One creates instantiations (we already use "instances" for a different
meaning) using PROCEDURE (in its four variations).  Suppose one has an
abstract procedure B, and one wants an instantiation of it named A, with
kind parameter K.  One then would write

  PROCEDURE(B(K)) :: A

In the <procedure-declaration-stmt> case this creates an instantiation
named A.  In the TBP case, K could be a kind parameter of the type, in
which case the processor creates an instantiation where an object of the
type is declared.  The instantiation has a secret name known only to the
processor, and a binding name of "A."  This is the solution of the last
problem of integrating PDTs and TBPs.

Instantiation creates an internal or module subprogram, never an
external subprogram.  An instantiation is considered to be internal to
the host of the abstract subprogram's definition, although its name
might be more local, e.g., confined to a BLOCK.  Host association is
determined by where the abstract subprogram is defined, not where it is
instantiated.  Therefore, an abstract procedure definition is not
allowed to appear in an internal subprogram.

Parameterized procedures and instantiations of them have a relationship
very much like the relationship between parameterized derived types and
objects of the type.

The scheme is compatible with parameterized modules or macros, so if we
decide to do one of those later, to gain additional functionality, there
would be no significant integration problem.

I have written out the details, covering procedures, procedure pointers,
procedure pointer components, interface blocks, and TBP bindings,
without edits, in a four-page draft paper.

I haven't a firm idea how difficult it would be to implement, but I
believe it would be far simpler than PDTs.  Each developer might have a
different opinion, depending upon the implementation methods used in
each processor.

Syntax is incredibly simple.  Specs are not terribly complicated.  I
suspect edits would add fewer than five pages to the standard, maybe as
few as three.

Does anybody want to see the draft paper?  If desired, I can prepare
preliminary edits to get a feel for how much impact it would actually
have.