(j3.2006) Comment concerning TEAM_TYPE

Malcolm Cohen malcolm
Tue Oct 8 00:56:21 EDT 2013


On 10/7/13 5:36 PM, Van Snyder wrote:
> For LOCK_TYPE and EVENT_TYPE, it is specified that all components have
> default initialization.  This means that one can use the type
> constructor.

I share Bill's puzzlement at the idea that this might be useful.

In fact, I would go so far as to say that enabling the type constructor for 
LOCK_TYPE was almost certainly inadvertent - I recall no discussion of this 
point at all.

>It is desirable to be able to use the constructor, presumably giving a
>"never appeared in a FORM TEAM statement that was executed" value.
>Otherwise, an object with a TEAM_TYPE component cannot be initialized.

If nothing in TEAM_TYPE is default-initialised, there is no problem with partial 
initialisation.

If everything in TEAM_TYPE is default-initialised, one does not need the 
constructor at all.

One can enable full initialisation without the constructor by overloading the 
type name with a generic name whose only specific is a function that returns an 
unusable type.  Some might think that slightly perverse.

>> > The TS ought to say explicitly that they all do have default
>> > initialization, or that there is at least one that does not, so users
>> > will know whether the type constructor can be used.
>>
>> I assume that the default is always that things are not default
>> initialized, but that could be stated explicitly.

Everything not stated about the components of a derived type would not be 
standardised.  Depending on the wording, this would likely make any program 
depending on said characteristics not conforming.  This is a bit stronger than 
"processor dependent", which makes said programs not portable instead of not 
conforming.

>It should be stated.

We should certainly state what we intend to standardise.  Whether we intend to 
standardise this I cannot say.  Even if we do want to allow the structure 
constructor to be used, perhaps that should only be permitted in an 
initialisation, and not, for example, as an actual argument.

One might also wonder about the utility of such things as
   Type(team_type) x
   Call s(Transfer(123,x))
I mean, this is bad enough with LOCK_TYPE but with TEAM_TYPE the results should 
be hilarious.  Some additional requirements along the lines of "the result of a 
function reference shall not be of type TEAM_TYPE" might be worth considering.

While I thinking of strange things, this seems to be valid:
  CLASS(*),POINTER :: a,b
  TYPE(team_type),TARGET :: x
   a => x
  FORM TEAM(a,13)
   ALLOCATE(b,SOURCE=a) ! TEAM_TYPE with POINTER attr?
   SELECT TYPE(b)
   TYPE IS (team_type)
      SYNC TEAM(b) ! b is a copy of a?
   END SELECT
   DEALLOCATE(b) ! Deallocating TEAM_TYPE is ok?

...perhaps we ought to consider forbidding TARGET with TEAM_TYPE too, otherwise 
half of the constraints are pretty pointless.  Or adding runtime requirements.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo. 




More information about the J3 mailing list