(j3.2006) parameterized derived types

[Tom Clune]

I agree that something should be done to fix this issue.   But I will also chime in that, as a user, I would have little sympathy for another user that fell into this abyss. 

Aside from backwards compatibility concerns, I think I?d be fine with Malcolm?s ?zz? option, though I?m open to examples that would change my mind.     


> On Dec 10, 2015, at 7:34 PM, Cohen Malcolm <malcolm at NAG-J.CO.JP> wrote:
> 
>> 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. 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 	<Thomas.L.Clune at nasa.gov>
Software Infrastructure Team Lead
Global Modeling and Assimilation Office, Code 610.1
NASA GSFC		
MS 610.1 B33-C128
Greenbelt, MD 20771
301-286-4635













-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20151210/7f5c8b60/attachment-0001.html