(j3.2006) Problem with default expressions for kind type parameters?
Bill Long
longb
Fri Sep 21 16:45:58 EDT 2012
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.
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
>
--
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101
More information about the J3
mailing list