(j3.2006) parameterized derived types

[Van Snyder]

On Wed, 2015-12-09 at 20:43 +0000, Bill Long wrote:
> I?ll agree that there is a problem.  I just don?t think the problem is
> tied to PDTs.   It?t rooted in the ability for users to change
> rounding modes combined with allowing specification expressions to
> involve floating point operations.

While J3 was briefly pondering interval arithmetic, there was a proposal
from /Interval in 98-126r1 to provide rounded operations, such as +>,
+<, etc.  It fell on deaf ears.  This wouldn't specify which way
SQRT(5.0) is rounded, but 0+>SQRT(5.0) would.  The proposal didn't
suggest a syntax for rounding to nearest or rounding toward zero.

98-126r1 also proposed ROUND_UP and ROUND_DOWN intrinsic functions.  If
those were provided, along with ROUND_NEAREST and ROUND_ZERO, and the
rounding mode that is used in specifications if those functions or
operators did not appear were specified, and specified to apply
independently of the mode in effect when a specification expression is
evaluated, including in ALLOCATE statements, perhaps the problem Bob
noticed could be avoided.

If roundings could be explicitly specified in specification expressions,
one could require that it be specified consistently for, for example,
actual and dummy arguments, or pointers and targets.

If no provision is made to specify a rounding mode within an expression,
an alternative is for the standard to specify which rounding mode is
used in specification expressions, independently of whatever rounding
mode is in force for executable statements.