(j3.2006) assumed-size poly actual -> non-poly dummy

Aleksandar Donev donev
Thu Jan 27 17:30:34 EST 2011

On 01/27/11 15:34, Bill Long wrote:
> I did not find a similar ban for an
> assumed-size actual corresponding to a polymorphic dummy.  I think this
> is the ultimate issue here.
This may be off the wall, as my previous comment, but...The reason I 
originally said it is not legal is because it definitely looks like 
something that ought not to be legal. But then, it seems it was by 
design....I read the words but then read them as if they said:
"A nonpolymorphic entity is type compatible only with nonpolymorphic 
entities of the same type."
which seems like the sensible thing to do to me.

If a dummy really needs to be able to accept an actual of uknown type, 
it should be polymorphic. Pretending like an object of class(t) is of 
type(t) is simply wrong, it is not (the reverse is true), and thus we 
have select type. It contains a subobject thereof, for which we have 
very nice notation, object%parent_component. So in your example, if the 
user really wanted to pass a polymorphic object as an actual to a 
non-polymorphic dummy, it ought to do:
call B(x%parent)
and not
call B(x)

Then, there should be a rule prohibiting x%parent without any subscript 
selectors. Surely we have a rule that prohibits this code:

type(t) :: x(*)

call B(x%integer_component) ! Dummy is assumed-size integer array

This requires copy in/out and should be forbidden in F90 (cannot find 
the rule though).


Aleksandar Donev, Assistant Professor of Mathematics
Courant Institute of Mathematical Sciences
Office: 909 Warren Weaver Hall, New York University
E-mail: donev at courant.nyu.edu
Phone: (212) 992-7315; Fax: (212) 995-4121
Mailing address: 251 Mercer St, New York, NY 10012
Web: http://cims.nyu.edu/~donev

More information about the J3 mailing list