(j3.2006) Question about specification expressions

[Cohen Malcolm]

I think there is some unnecessary panicking going on here.  The conditions 
on (b) are on (b), not on (a).

The claim

  "7.1.11p2(9)(b)(ii) says that if a specification inquiry appears in a 
specification expression, a variable that is an argument cannot be an 
optional dummy argument (which A is not), and the property inquired cannot 
be deferred."

is untrue.  That restriction only applies to a specification inquiry whose 
argument is not "a restricted expression".

No change is necessary or desirable.

Cheers,

-----Original Message----- 
From: Van Snyder
Sent: Thursday, March 10, 2016 10:32 AM
To: j3
Subject: (j3.2006) Question about specification expressions

In this little program

program P

  integer, allocatable :: A(:)
  integer :: N

  read ( *, * ) n
  allocate ( a(max(n,1)) )

  a(1) = size(a,1)

  block
    integer :: B(size(a,1)), C(a(1))
    ...
  end block

end program P

Is the declaration of B acceptable?

7.1.11p2(9)(b)(ii) says that if a specification inquiry appears in a
specification expression, a variable that is an argument cannot be an
optional dummy argument (which A is not), and the property inquired
cannot be deferred.

The bound of A is deferred.  Is the size still deferred after A is
allocated?  If so, the declaration of B is invalid.

There is nothing in 7.1.11 about allocatable variables (or pointers), so
the declaration of C is apparently acceptable.

It seems a bit bizarre to prohibit using an inquiry of the size of an
allocatable array in a specification expression, but not saying anything
about using the value of an element of that array in a specification
expression.

Change the ALLOCATABLE attribute of A to POINTER and the same questions
arise.

Change the inquiry to one about a deferred length parameter and the same
questions arise.

Make the variable a module variable and try to use it in a specification
expression in a module procedure and the same questions arise (i.e., the
BLOCK is a red herring).

It seems that 7.1.11p2(9)(b)(ii) was a bit overzealous.  It's not
permitted to reference an undefined variable in any expression.  If a
reference to an unallocated variable appears in a specification
expression, that's taboo, but couldn't be prevented in 7.1.11p2 because
that's effectively part of a constraint.  Prohibiting reference to a
deferred property, that might not be deferred when it's inquired, seems
a hit harsh.

Does this need (or would it benefit from) an interp?

Or should I add a regularization of this to my 56-page wishlist?

The regularization would be either
(1) Delete 7.1.11p2(9)(b)(ii) (my preference), or
(2) Prohibit reference to pointer or allocatable variables in
specification expressions (incompatible change).


_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3

________________________________________________________________________
This e-mail has been scanned for all viruses by Star.
________________________________________________________________________

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