(j3.2006) Problem with default expressions for kind type parameters?

[Van Snyder]

On Fri, 2012-09-21 at 15:45 -0500, Bill Long wrote:
> 
> On 9/21/12 3:38 PM, Van Snyder wrote:
> > On Fri, 2012-09-21 at 10:47 -0500, Bill Long wrote:
> >> Revising Van's example leads to another question:
> >>
> >> type t(j,k)
> >>      integer,kind :: j = 5
> >>      integer,kind :: k = j+1
> >> end type t
> >>
> >> type(t) :: v
> >> type(t(j=10)) :: w
> >> print *, v%j, v%k
> >> print *, w%j, w%k
> >> end
> >>
> >> Assuming this is allowed at all, what is expected for w%k?  I could see
> >> an argument for either 6 or 11.  I think it would be better to just
> >> restrict the initialization expressions for a KIND type parameter in a
> >> type definition to be a scalar integer constant.
> >
> > I don't see an argument for w%k == 6.
> 
> It depends on whether the compiler can determine the initialization 
> value for k = (5+1) at the time the definition of the type is compiled, 
> which would be consistent with the previous concepts of "initialized", 
> or whether the compiler has to dynamically recompute the initialization 
> values for every declaration of a variable of the type.   I can assure 
> you that the second option will further deter vendors from implementing 
> this feature.

Since

type t(j,k)
      integer,kind :: j
      integer,kind :: k = j+1
end type t

is admitted by the syntax, and not prohibited by a constraint, the
processor clearly needs to evaluate the "k" kind type parameter of an
object when it is declared, not when the type is defined.

> Cheers,
> Bill
> 
> >
> >> Cheers,
> >> Bill
> >>
> >>
> >> On 9/20/12 10:17 PM, Van Snyder wrote:
> >>> A type parameter name in a type definition is a valid primary in a
> >>> constant expression (7.1.12p1(9)).
> >>>
> >>> One need not specify kind type parameter values in the declarations of
> >>> objects of a type if there is a default in the type definition.
> >>>
> >>> There appears to be a problem with this:
> >>>
> >>>     type :: T(J=k+1,K=j+1)
> >>>       integer, kind :: J, K
> >>>     end type T
> >>>
> >>>     type(t) :: V
> >>>
> >>> Do we need a constraint something like this?
> >>>
> >>> C438a (R431) There shall not be a circular dependence between a
> >>>         <scalar-int-constant-expr> in a <type-param-decl> and any
> >>>         <type-param-name> in the same <type-param-decl-list>.
> >>>
> >>> A bigger hammer, perhaps larger than necessary, is
> >>>
> >>> C438a (R431) A <type-param-name> shall not appear in a
> >>>         <scalar-int-constant-expr> in the same <type-param-decl-list>.
> >>>
> >>> A medium-size hammer, easier to check than the first one, is
> >>>
> >>> C438a (R431) A <type-param-name> that appears in a
> >>>         <scalar-int-constant-expr> in a <type-param-decl-list> shall
> >>>         be declared earlier in that <type-param-decl-list>.
> >>>
> >>> I think this is the tiniest hammer that works (maybe):
> >>>
> >>> C485a (R453) If there is a circular dependence between a
> >>>         <scalar-int-constant-expr> in a <type-param-decl> and any
> >>>         <type-param-name> in the same <type-param-decl-list>, a
> >>>         <type-param-value> shall be provided for at least one of
> >>>         the <type-param-name>s in the circular dependency relationship.
> >>>
> >>>
> >>> _______________________________________________
> >>> J3 mailing list
> >>> J3 at mailman.j3-fortran.org
> >>> http://mailman.j3-fortran.org/mailman/listinfo/j3
> >>>
> >>
> >
> >
> > _______________________________________________
> > J3 mailing list
> > J3 at mailman.j3-fortran.org
> > http://mailman.j3-fortran.org/mailman/listinfo/j3
> >
>