(j3.2006) Alternative to macros or parameterized modules

[Van Snyder]

The motivation I originally had to advocate for parameterized modules or
macros was to make it easier to create a parameterized derived type
(with kind parameters) along with a consistent set of type-bound
procedures.

The problem, as Richard pointed out in about 1998, is that parameterized
types and type-bound procedures were not completely integrated.

One could, for example, create a parameterized type, and write a few
type-bound procedures for it using, say, default real.  Then, if one
instantiates an object of the type with a kind for double precision, the
type-bound procedures aren't there.

An alternative to offering users a solution based upon parameterized
modules or macros, is to allow to define type-bound procedures within
the type definition.  One could then declare dummy arguments, result
types, etc., using the kind type parameters of the type.

The processor would need to instantiate the type-bound procedures for
each spectrum of kind type parameters actually used to declare objects
of the type.  Most simply, this would be a separate set within each
scoping unit, but as an improved quality of implementation the processor
could keep a database of instantiated procedures, perhaps as a library,
and not generate duplicates.  The same problem and consideration arises
concerning parameterized modules.

This is less flexible than macros or parameterized modules, but might be
easier (or harder) to explain in the standard, and easier (or harder) to
implement.

On the other hand, it would be easier to guarantee that the type-bound
procedures are available no matter what (valid) kind type parameters are
used to instantiate objects of the type.

With macros, the author would need to anticipate all possible
combinations of valid kind type parameters, and write macros that
carefully iterate over that entire space, to construct the type-bound
procedures, and generate the type bindings and any generic bindings.
It's possible to do this, but gets ugly quickly.

With parameterized modules, the obvious thing to do is to put a type and
its type-bound procedures into the same parameterized module.  Then,
when it's instantiated with kind type parameters, one gets a consistent
type and type-bound procedures.  We do not, however, offer the
equivalent of "generic" for type definitions, so one effectively doesn't
get parameterized types: If one wants to use different kinds with the
same type in a single scoping unit (trivial with parameterized types)
each use of the instantiated module would need to re-name the type
differently.  Then objects would need to be declared with those
different type names, instead of a single type name with different kind
type parameters.

Of course, macros or parameterized modules have uses independent from
producing a type and a consistent set of type-bound procedures.  Maybe
both courses ought to be pursued.