(j3.2006) Lock variables

[Van Snyder]

On Sun, 2009-03-08 at 17:53 -0700, Malcolm Cohen wrote:
> 
> Van Snyder wrote:
> > Does C608 at [09-007:118:5-6] serve a purpose other than to try to make
> > a tiny almost invisible dent in the possibility to write a silly or
> > nonfunctional program?
> >   
> Giving error messages at compile time rather than inscrutable behaviour 
> at runtime seems like a worthwhile ambition.

There's nothing more or less inscrutable that's an effect of a lock
being or not being a coarray.   A noncoarray lock either gets locked and
unlocked silently and "correctly" (exactly as it would if it were a
noncoindexed coarray lock), or it causes an error message about the same
image locking it twice (exactly as it would if it were a noncoindexed
coarray lock) or the program gets an "it's already locked" status
(exactly as it would if it were a noncoindexed coarray lock).  For now,
it would just be a silly program that locks a noncoarray lock -- until
we implement task parallelism, at which time it will make sense.
Fortran 2008 isn't out the door yet, and the lack of task parallelism is
already being criticized.

> > Do we want to prohibit a lock variable from being an <output-item>?
> >   
> It's already done except for the case of defined i/o.

It's not completely done.  It's OK that it's not done for defined I/O
because if we get it right at the non-defined-I/O level, the procedure
that ultimately does non-defined I/O won't be able to do I/O on locks.

> > It's silly to do it (which is only possible in an unformatted write
> > statement because it has private components).
> Where does it say unformatted write doesn't have to obey the requirement 
> that all
>    "components shall be accessible in the scoping unit containing the 
> input/output statement"
> ?

That requirement is in 9.6.3p7, the second bullet in the list, at
[09-007:220:6-10], which deals with derived-type list items that get
decomposed into their components because at least one component is
handled by defined I/O.  This is all in one sentence under the qualifier
that explains when the list item gets decomposed, so I don't see how it
applies anywhere else.  It appears again in the fourth bullet for
formatted I/O at [220:14-17].

There is no such similar requirement in the third bullet, which deals
with list items that don't get decomposed.  Down in the fifth bullet
[220:18-20] (which ought to be part of the third one) it gets around to
prohibiting ultimate components of derived-type list items that aren't
decomposed from having the ALLOCATABLE or POINTER attributes.  But
there's still nothing there about the ultimate components being
accessible.  NOTE 9.34 suggests this was intentional.