(j3.2006) Unlimited polymorphic and LOCK_TYPE (and EVENT_TYPE)

[Van Snyder]

On Tue, 2014-06-03 at 16:16 +0000, Bill Long wrote:
> Ultimately, I think this discussion arises from the sentence ?A scalar
> variable of type EVENT_TYPE is an event variable.? since the
> subsequent discussions are all about event variables.  The key
> requirement is that the type referred to here is the *declared* type
> and not the dynamic type.  Eventually you can deduce this since later
> constraints on event variables would not work for dynamic types.  It
> might be easier to remove the puzzle-solving requirement and up front
> say ?declared type? in the sentence above -> ?A scalar variable of
> declared type EVENT_TYPE is an event variable.?.

That's not why I became concerned and/or confused.

My concern for unlimited polymorphic with dynamic type involving
LOCK_TYPE arose from 14-007r1:C438.  There is no parallel constraint
concerning EVENT_TYPE in 14-130.

C438 prevents hiding a component of type LOCK_TYPE under an extension of
a declared type that doesn't have a component of type LOCK_TYPE, using a
polymorphic object of that declared type, to circumvent C1304.

If it is important to have a constraint against that, it seems important
to constrain against hiding an object involving type LOCK_TYPE under an
an unlimited polymorphic object.

It can't be done with a constraint like C438.  It is possible to
constrain against creating one using ALLOCATE, or associating an
unlimited polymorphic pointer with one.

As Malcolm suggests, the question is whether we want to bother with it.
We have some run-time prohibitions, but as has been made clear in other
correspondence on other topics, we frequently prefer to give
compile-time messages where possible.

A simpler example than the earlier one would be

  type(lock_type), save, target :: A[*], B[*]
  class(*), allocatable :: C, D
  logical :: GOT_IT

  lock ( a )
  allocate ( c, source=a ) ! locks c

  select type ( c )
  type is ( lock_type )
    lock ( c, acquired_lock = got_it )
    if ( .not. got_it ) print *, "How was C already locked?"
  end select

  allocate ( d, source=b ) ! unlocks d
  c = d ! unlocks c

  select type ( c )
  type is ( lock_type )
    lock ( c, acquired_lock = got_it )
    if ( got_it ) print *, "How did C get locked again?"
  end select

C643 doesn't constrain against the allocations because C and D are not
coarrays.  C1303 doesn't constrain against them because C and D are not
named variables of type LOCK_TYPE or have potential subobject components
of type LOCK_TYPE.  7.2.1.2p1(1) doesn't prohibit the assignment because
C is allocatable and not a coarray.

Do we want to constrain against this, or not?

If so, C643 should be split into two constraints:

C643 (R626) The declared type of <source-expr> shall not be C_PTR or
     C_FUNPTR if an <allocate-object> is a coarray.

C643a (R626) The declared type of <source-expr> shall not be LOCK_TYPE
      or have a potential subobject component of type LOCK_TYPE, and
      <type-spec> shall not specify LOCK_TYPE or a type that has a
      potential subobject component of type LOCK_TYPE, if any
      <allocate-object> is unlimited polymorphic.

To cover the part in the current C643 concerning LOCK_TYPE and a coarray
<allocate-object>, revise C1303 and C1304 by replacing
"<allocate-object>" with "<allocate-object> in a DEALLOCATE statement or
in an ALLOCATE statement without a SOURCE= <alloc-opt>" (Compare to C602
and C603 in 14-130).

To avoid something as simple as

  c = a ! Unlock C

after item (1) in 7.2.1.2 add

(1') if the variable is unlimited polymorphic, <expr> shall not be of
     type LOCK_TYPE or have a subcomponent of type LOCK_TYPE.

(It would be helpful if items(1-7) of 7.2.1.2 were in constraints.)

Constraining against pointer assigning an object involving type
LOCK_TYPE to an unlimited polymorphic object is still necessary, even
though a polymorphic pointer cannot be the variable in an intrinsic
assignment.  There are other variable definition contexts where one can
appear, in particular as an actual argument corresponding to a
nonpointer INTENT(OUT) dummy argument.

C716a (R733) If <data-pointer-object> is unlimited polymorphic,
      <data-target> shall not be of type LOCK_TYPE or of a type that
      has a potential subobject component of type LOCK_TYPE.

This constrains against

  type(lock_type), save, target :: A[*]
  class(*), pointer :: B
  logical :: Got_It
  lock ( a )
  b => a
  call hidden_unlock ( b )
  select type ( b )
  type is ( lock_type )
    lock ( b, acquired_lock = got_it )
    if ( got_it ) print *, "How did I get the lock?"
  end select

  contains
    subroutine hidden_unlock ( C )
      class(*), intent(out) :: C
    end subroutine hidden_unlock

The actual argument associated with C is required to be definable
(5.3.10p3), but 13.8.2.16 doesn't say that objects of type LOCK_TYPE are
not definable except in LOCK or UNLOCK statements.  Even if it did, it
would be nice to get a constraint error at the pointer assignment
instead of inexplicable results or a seg fault.

> Cheers,
> Bill
> 
> 
> On Jun 2, 2014, at 7:04 PM, Malcolm Cohen <malcolm at nag-j.co.jp> wrote:
> 
> > Hi Bill,
> > 
> > Interesting new example....
> > 
> >> class(*),allocatable :: myevent[:]
> >> ?
> >> allocate (event_type :: myevent[*] )
> > 
> > I don't offhand see any problem with this code, even without MYEVENT being a 
> > coarray, but then again it also does not achieve anything.  The only way you can 
> > achieve anything is to follow it up with something like
> > 
> >  SELECT TYPE (letter=>myevent) ! Renaming merely for exposition.
> >  TYPE IS (event_type)
> >    POST letter
> > 
> > at which point my previous reasoning comes into play: the construct entity 
> > LETTER is declared to be of type EVENT_TYPE and is therefore required to be a 
> > coarray; in your example it is (construct entities have the same corank and 
> > cobounds as the selector), so the code would be ok.  If myevent were not a 
> > coarray, the ALLOCATE would be ok (as in, would not fail any current constraint) 
> > but any attempt to actually use it as an event variable is inevitably going to 
> > run afoul of the "required to be a coarray" constraint.
> > 
> > That is certainly what we would seem to have for LOCK_TYPE.  It could be argued 
> > that this was unintentional (since it is useless) and that therefore we ought to 
> > have had a constraint on it in F2008.  That would be interp fodder if so.  For 
> > EVENT_TYPE we are not constrained by what we did in F2008 but for consistency it 
> > is probably good to make it similar to LOCK_TYPE except in so far as it is 
> > different because it is an event not a lock.
> > 
> > Cheers,
> > -- 
> > ................................Malcolm Cohen, Nihon NAG, Tokyo. 
> > 
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> 
> Bill Long                                                                       longb at cray.com
> Fortran Technical Suport  &                                  voice:  651-605-9024
> Bioinformatics Software Development                     fax:  651-605-9142
> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3