(j3.2006) Lock variables

Malcolm Cohen malcolm
Sun Mar 8 20:53:09 EDT 2009



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.
> "C608 A data entity that is or has an ultimate component of type
> LOCK_TYPE in the intrinsic module ISO_FORTRAN_ENV shall be a coarray."
>
> UTI 156 could be addressed simply by deleting the constraint.
>   
UTI 156 has already been addressed.  With luck, 09-007r1 will be 
available next week and you can critique that version instead.
> 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 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"
?

> Prohibiting lock variables in variable definition contexts (except as
> the <lock-variable> in a LOCK or UNLOCK statement) was probably too big
> a hammer: we prohibited lock variables from being actual arguments
> associated with dummy arguments having intent(inout),
I agree that seems unfortunate.
>  from being pointer
> objects in NULLIFY statements,
Coarrays are already prohibited from being pointers.
>  and from being data pointer objects in
> pointer assignment statements.
Coarrays are already prohibited from being pointers.
>   This makes the POINTER and TARGET
> attributes pointless.
POINTER is explicitly prohibited, so the ultimate in pointerless.
>   If this really was what we wanted, perhaps we
> should also prohibit them from being dummy arguments (and therefore
> actual arguments),
Obviously we didn't intend this.  From where I'm sitting anyway.
>  and from having the ALLOCATABLE,
Wrong.  ALLOCATABLE is a very useful attribute for coarrays.


Let's wait and see what we have in 09-007r1 before deciding that that 
version is useless.

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





More information about the J3 mailing list