(j3.2006) Is 7.2.1.2p1(1) necessary?

[Tom Clune]

On Mar 11, 2015, at 9:51 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> 7.2.1.2p1(1) says "if the variable is polymorphic it shall be
> allocatable and not a coarray."
> 
> This makes it impossible to assign to an element or section of a
> polymorphic array without a SELECT TYPE construct.  Indeed, two nested
> SELECT TYPE constructs are needed, to avoid violating 7.2.1.2p1(4).
> 
>    if ( .not. SAME_TYPE_AS ( v, e ) ) &
>      & call Stop_With_Error_Message ( "Wrong Types" )
>    SELECT TYPE ( v )
>    TYPE IS ( <whatever> )
>      SELECT TYPE ( e )
>      TYPE IS ( <same whatever> )
>        v(i) = e
>      END SELECT
>    END SELECT
> 
> As Tom mentioned, this would be easier if SELECT TYPE could have more
> than one selector:
> 
>    SELECT TYPE ( v, e )
>    TYPE IS ( <whatever>, <same whatever> )
>      v(i) = e
>    END SELECT

As much as I?d like to take credit,  I think this situation is a bit different than what I discussed at the last meeting.  There I merely suggested a textual simplification of combining two ranks in one RANK selection block.   I.e. the analogy in your case would be:

SELECT TYPE (q)
TYPE IS (r, s) ! type r _or_ type s
	?
END SELECT TYPE

E.g. if (r,s) were (INTEGER, REAL) and the ? were   q = 1, then it would be clear to the reader and the coder.   But apparently causes apoplexy for the compiler developers!  :-)

Here you have two actual selectors.      Not voicing an opinion on the matter, just a clarification.

The few times I?ve encountered this issue, I?ve generally been happy once I found a place to put an appropriate method (type bound procedure) for doing the actual assignment.   This easily and gracefully sidesteps the need for the nested SELECT TYPE, and is almost every case eliminates any need for any SELECT TYPE at all.    The Visitor design pattern (also called Bridge) is the common situation where something like this arises.

(BTW, I usually cannot sleep at night if I find myself forced to use a SELECT TYPE in my code - screams that there is a design problem.)
Cheers,

- Tom



> 
> Bit is it really necessary for it to be allocatable?  Would it be enough
> to require that if it is not allocatable, variable and expr shall have
> the same dynamic type?
> 
> For polymorphic assignment, as it stands now, processors have to check
> the dynamic type anyway, either to allocate the variable with that type,
> or at least to determine whether the dynamic types are the same if they
> want to bypass re-allocating the variable in that case.  So checking the
> dynamic types, and raising an error condition if they're different,
> isn't any more difficult that what's required now.
> 
> 
> 
> _______________________________________________
> 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>
Head ASTG,Code 606
NASA GSFC		
MS 610.8 B33-C128
Greenbelt, MD 20771
301-286-4635









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150312/dc071c08/attachment-0002.html