(j3.2006) parameterized derived types

[Cohen Malcolm]

>Bounds have been determined dynamically at run time for ages.

That is not what we are talking about.

>I?ll agree that there is a problem.  I just don?t think the problem is tied
>to PDTs.

You are mistaken.  The whole fundamental principle behind types and type 
parameters is that objects with the same type and type parameter values have 
the same properties, and can have (and usually do have) the same internal 
representation.

The issue with component specification expressions means that X and Y, of 
the same type, and with the same type parameter values, might have different 
properties: that is, corresponding components of X and Y have different type 
parameter values or array bounds even though X and Y have the same type 
parameters!

This is clearly nonsensical.

>   It?t rooted in the ability for users to change rounding modes combined
> with allowing specification expressions to involve floating point
> operations.

There is no problem with normal "specification expressions" at all.  Normal 
specification expressions are not expected to give the same results when you 
evaluate them in separate instances.  Component specification expressions 
are fundamentally different, seeing as how they are part of the type 
infrastructure.  (And prior to type parameters, were required to be 
constant.)

There are a number of fixes possible, ranging from
(a) requiring the processor to produce the same values of component 
specification expressions given the same type parameters regardless of 
context
to
(z) requiring any floating-point operation or function reference in a 
component specification expression to be a constant expression.

Or (zz) forbidding floating-point from component specification expressions; 
but I think (z) is sufficient.

As it stands, the standard is contradictory at best, and unimplementable at 
worst.  Clearly undesirable.

(For clarity, it would probably have been better to actually draw up a set 
of proper "component specification expression" rules instead of mangling the 
normal "specification expression" rules into doing what we meant.  It might 
have given us a better chance of noticing this kind of nonsense earlier! 
But that would be an editorial change only.)

Cheers,
-- 
........................Malcolm Cohen, Nihon NAG, Tokyo.