(j3.2006) Materials for 199

[Van Snyder]

On Thu, 2012-09-27 at 16:25 -0500, Bill Long wrote:
> Some sort of template scheme would be convenient.  Van proposed an 
> interesting syntax style, but focused on KIND type parameters which 
> should be a low priority since we have SELECTED_*_KIND routines to 
> choose the desired KIND up front.

This entirely misses the point.

SELECTED_*_KIND can choose the KIND up front, but doesn't solve the
problem of integrating PDTs with TBPs, so "low priority because..."
doesn't actually mean anything.

Suppose you write a PDT with TBPs for single and double precision.
Years later, somebody wants to use it with SELECTED_REAL_KIND(30) for
one of the kind parameters of the type, and finds that although his
processor provides real data objects of that kind, there is no TBP for
that kind.  He can copy the TBPs, change their type parameters, and add
bindings for them.  This gets tedious if there are several TBPs.  A
kludge using "include" makes it a bit easier, but still ugly.  There may
be contractual, copyright, or patent reasons for it to be difficult,
maybe even impossible, not just tedious.  Recertification might be
expensive.

I aimed explicitly at this problem, which Richard Maine enunciated more
than a decade ago.  Parameterized modules, consciously based on Ada
generic packages, were aimed at this problem.  Macros would have solved
the problem.

>   Being able to have substitutable 
> types for the arguments would be more interesting.

The scheme I proposed is extensible to allow the parameter names to be
types, or data objects of any type and kind, so it's not a dead end.  I
intentionally minimized the proposal, to be consistent with Toronto
resolutions.