(j3.2006) (SC22WG5.4222) What shall we do with the broken feature?

[Bill Long]

Dan Nagle wrote:
> Hi,
> 
> I vote with Bill.
> 
> Quick fixes chance errors, processing an Interp allows
> time for more in-depth thought.
> 
> No one is implementing this today,

I would not go that far (well ok, maybe not TODAY). But those who are 
read this list and are aware of the issue.

Cheers,
Bill



> we can take the time to do it right.
> 
> On Mar 17, 2010, at 4:19 AM, Malcolm Cohen wrote:
> 
>> The facility of being able to pass a null pointer or unallocated  
>> allocatable to an optional nonpointer nonallocatable dummy argument  
>> and have that treated as being an absent dummy argument is broken as  
>> follows.
>>
>> (i) All of the optional DIM arguments to the intrinsic functions  
>> that change the rank are qualified with "The corresponding actual  
>> argument shall not be an optional dummy argument.".  Previously it  
>> was not permitted to pass a null pointer here, now it is permitted  
>> and gives a runtime-varying rank depending on the association status  
>> of the pointer.  E.g. PRODUCT(matrix,pointer_to_dim) is rank 1 if  
>> pointer_to_dim is associated and rank 0 if it is not.  20 functions  
>> have a prohibition against optional dummy arguments, but in several  
>> of those it is an unnecessary prohibition so fewer than 20 would be  
>> necessarily affected.
>>
>> (ii) This feature appears to change the results of ASSOCIATED when  
>> TARGET is a null pointer.  This does not appear on the surface to be  
>> fixable other than by specifying that the feature does not apply to  
>> this particular intrinsic function, which might be confusing.
>>
>> (iii) Minor: The performance of a few intrinsic functions such as  
>> MAX when some arguments are pointers is adversely affected.
>>
>> (iv) Nitpick: the description in the Introduction omits the  
>> unallocated allocatable case.
>>
>> How should we address the problem?
>> (1) fix the DIS by deleting the feature (I don't think we have a  
>> mandate for that though);
>> (2) fix the DIS by changing the wording;
>> (2) leave it to be fixed later via interpretation processing (other  
>> than the nitpick which should be done anyway).
>>
>> Comments?
>>
>> Cheers,
>> -- 
>> ................................Malcolm Cohen, Nihon NAG, Tokyo.
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at j3-fortran.org
>> http://j3-fortran.org/mailman/listinfo/j3
> 

-- 
Bill Long                                           longb at cray.com
Fortran Technical Support    &                 voice: 651-605-9024
Bioinformatics Software Development            fax:   651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101