(j3.2006) Variable definition context

[Van Snyder]

I should have offered more reasons for being curious about this.

The first is the observation that in every reference to 16.6.7, other 
than the ones on page 316 concerning pure procedures, the objects 
discussed in relation to variable definition context are clearly 
nonpointer objects.  Allocatable objects are admitted in some of those 
discussions.

Therefore, other than for pure procedures, restrictions in 16.6.7 that 
deal exclusively with pointers are (to pardon the intended pun) pointless.

If variable definition context were change as obliquely suggested in the 
original message, the constraints concerning pure procedures could be 
covered by reference to pointer association context.

The second is the observation that one cannot have a meaningful pointer 
of a type that has a potential subobject component of LOCK_TYPE.  It can 
exist, but it cannot even be nullified, let alone associated with an 
object.  One cannot, for example, make a linked list of objects that 
have LOCK_TYPE components.

I suspected that pointers of LOCK_TYPE are prohibited, but the closest 
thing I could find to prohibiting them is that targets of pointers 
cannot be coindexed objects.  That doesn't prohibit a pointer from 
having a target that is a coarray.

The third reason is that one can imagine uses of LOCK_TYPE pointers, if 
they are allowed, but with the existing prohibitions in 16.6.7 one 
cannot associate them.

Changing 16.6.7 as obliquely suggested would both shorten 16.6.7 and 
allow linked lists of objects having components of LOCK_TYPE without 
adding a list of exceptions to C1303.

The reason for suggesting that "with explicit interface" ought to be 
included in the fourth list item in 16.6.8 is that C541 and C554 cannot 
actually constrain without it, because the processor cannot see the 
dummy argument intents.  Those two constraints are the only places that 
I found where "pointer association context" is mentioned.

Malcolm Cohen wrote:
> Van Snyder writes:
>
>   
>> 16.6.7p1(12) "Variable definition context" says
>>
>> "(12) an actual argument in a reference to a procedure with an explicit
>> interface if the corresponding dummy argument has INTENT (OUT) or INTENT
>> (INOUT);"
>>
>> is a variable definition context.
>>
>> Do we want that to be the case if the actual argument and dummy argument
>> are both pointers?
>>     
>
> Yes.  Note that pointer assignment, allocation, deallocation, and nullification 
> all appear on this list, so it is clearly intentional.
>
> ...
>   
>> If they are both pointers, the fourth item in the list in 16.6.8p1
>> "Pointer association context" says it's a pointer association context,
>>     
>
> Right, it is both in this case.
>
>   
>> using slightly different words:
>>
>> "an actual argument in a reference to a procedure if the associated
>> dummy argument is a pointer with the INTENT (OUT) or INTENT (INOUT)
>> attribute."
>>
>> This probably ought to
>>     
> [use "corresponding" not "associated"]
>
> I agree.  This is such a minor editorial item I've just added it to my draft 
> paper.
>
>   
>> 16.6.7p1 "Variable definition context" also has
>>
>> "(2) a pointer-object in a nullify-stmt;
>> "(3) a data-pointer-object or proc-pointer-object in a
>> pointer-assignment-stmt;"
>>
>> Are these really variable definition contexts, or are they pointer
>> association contexts?
>>     
>
> Yes and Yes.
>
>   
>> That these are now variable definition contexts
>>     
>
> I think these were always variable definition contexts.
>
>   
>> makes it impossible to
>> have a meaningful pointer of type EVENT_TYPE or a type that has a
>> component of type EVENT_TYPE (C602-C603 in the TS), or one of type
>> LOCK_TYPE or a type that has a component of type LOCK_TYPE (C1303-C1304
>> in 14-007).
>>     
>
> There are severe limits on this anyway (you are not even allowed to have a named 
> pointer of type LOCK_TYPE for example).  Actually I suspect the limits are more 
> likely to be not severe enough rather than too severe...
>
> Since events and locks are for inter-image communication, and POINTER does not 
> work inter-image, I think you should not be allowed to have pointers of those 
> types full stop.
>
>   
>> [488:23-24 C.4.4] says "where a pointer appears in a variable-definition
>> context the variable that is defined is the target of the pointer." This
>> certainly cannot be the case in 16.6.7p1(2-3).  This needs to be
>> repaired if 16.6.7p1(2-3) are not moved to 16.6.8.
>>     
>
> C.4.4p1 is broken anyway, since variable-definition context includes 
> undefinition which C.4.4 does not admit to.  And its first sentence has nothing 
> to do with the topic (but has to do with the topic of C.4.3!).
>
> As far as I am concerned the entirety of C.4 adds nothing to the standard and 
> could profitably be removed.  It was useful in F90 and in F95, but not since.
>
>   
>> The list in 16.6.7 "Variable definition context" is enumerated.  The one
>> in 16.6.8 "Pointer association context" is itemized.  Should they be the
>> same style?  ISO apparently prefers itemized, but enumerated makes for
>> easier reference.
>>     
>
> Ease of reference is only germane for big long lists.  I see no problem with us 
> continuing to enumerate big long lists and itemise short ones.
>
> Cheers,
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20140402/06e9d33c/attachment.html