(j3.2006) 08-267

Aleksandar Donev donev1
Wed Sep 24 13:10:37 EDT 2008


Van and Jim,

I will repeat, and Bill gave you the reference: The dynamic type must be the 
same on all images. This is by design. So Van's code:

>  > ? class(my_type), intent(in) :: x[*]
>  > ? select type ( x )
>  > ? type is ( my_extension )
>  > ? ? print *, x[1]%extra_stuff
>  > ? end select

is perfectly fine and it is the way to do what he wants (access components of 
the extended type on other images).

Jim pondered:
>  Hmm..., I don't even understand what this code fragment means: the
> associate name, x, in the select type construct is revering to a local
> variable
It refers to a coarray, i.e., a variable with corank 1. Sure, the variable 
is "local", all variables are, seing as how there is no concept of a "global" 
variable (not in this revision, thank you very much!).

> I think we should prohibit coindexed objects with base-object
> being associate name.
Why? The code makes perfect sense to me, and as I said, putting in arbitrary 
restrictions is a vv bad design idea. There may be good reasons to eliminate 
all mingling of ASSOCIATE and coarrays, but I don't see it in your post. We 
did prohibit the selector from being coindexed with good reasons.

I understand you hate ASSOCIATE and polymorphics because of the pains they 
cause to implement. IBM can simply not implement them, or should have 
objected in 2003. Now is not the time to backwards remove language elements 
we dislike (otherwise I will promptly send my list as well).

Best,
Aleks

-- 
Aleksandar Donev, Ph.D.
Lawrence Postdoctoral Fellow @ Lawrence Livermore National Laboratory
High Performance Computational Materials Science and Chemistry
E-mail: donev1 at llnl.gov
Phone: (925) 424-6816  Fax: (925) 423-0785
Address: P.O.Box 808, L-367, Livermore, CA 94551-9900
Web: http://cherrypit.princeton.edu/donev




More information about the J3 mailing list