J3/01-386 Date: November 29, 2001 To: J3 From: Dick Hendrickson Subject: Questions about associated names and variables in CH 8 1) I think we need a note describing the differences between ASSOCIATE and EQUIVALENCE, HOST association, pointers, and dummy argument association. The ASSOCIATE concept seems to share some of all of these, but isn't really the same as any of them. Possible we need to describe how the association really works--Is sort of like pointer association where the address of the target gets copied into the address part of the pointer? 2) I think section 2.4.3.1 needs to declare associate-name as a data object. I don't see anything in 8.1.4 that does this. 3) We need to rework R612 and its constraints. As it is now, there is no syntax rule that describes what associate-name%part-ref is. This may work out naturally if we do something for number 2) We also need to make sure that we disallow using the associate name as the middle name of a structure. Something like associate (x=> b%c) a%x%d = 0 !not a%b%c%d 4) We need to describe the relation between the associate-name and the real thing in the associate block. Suppose I do something like associate (assoc_name => poly_thing) ... !do something to poly_thing that gives it a new type !maybe deallocate and then reallocate Is this illegal? I think it should be, but what covers it. Similar question for allocatable or pointer selectors. associate (assoc_ptr => ptr, assoc_alloc => alloc ) ptr => something_else deallocate (alloc) ; allocate (alloc(10, 10) ) ... end associate Are those forms illegal, or does magic happen to assoc_ptr and assoc_alloc? Or something like associate (a_array => array(1:10) ) do i = 1,10 a_array(i) = array( some subscript expression ) + 1 enddo end associate Must the compiler do some sort of subscript analysis to make sure the do loop is done properly (i.e. associate is like equivalence), or can it assume the user guarantees there is no overlap (i.e. associate is like dummy arguments) and do full scale optimization? 5) Can the association produce something that is illegal in some contexts? Something like associate (assoc => poly_function(B_2D,C_3D)) !B_2D is of type point, !C_3D is of type 3D point which extends point where "assoc" will either be a 2D point or a 3D point depending on what poly_function does. If 3D point extends 2D point types then can I have something like if (expr) z = assoc%Z when poly_function returns a 2D point data type? Naturally expr would have to be false.