(j3.2006) a question on same_type_as and type parameters

[Jim Xia]

j3-bounces at j3-fortran.org wrote on 08/28/2008 02:44:21 PM:

> 
> On Thu, 2008-08-28 at 10:09 -0400, Jim Xia wrote:
> > The same question also applies to parameterized derived types as can
> > be illustrated by the following example 
> > 
> > 
> >     type t (k) 
> >         integer, kind :: k 
> > 
> >         real :: x(k) 
> >     end type 
> > 
> >     type (t(5)) a 
> >     type (t(10)) b 
> > 
> >     print *, same_type_as (a, b) 
> >     end 
> 
> This one would clearly print T, according to the definition of
> SAME_TYPE_AS.  In this case, one can reference the kind parameters of A
> and B without getting at their dynamic types using SELECT TYPE
> constructs.
> 
> We're stuck with the current definition of SAME_TYPE_AS, unless we're
> willing to make an incompatible change that probably wouldn't break any
> existing codes.
> 
> We could provide a different function to answer SAME_TYPE_AND_KIND_AS,
> and another one for length parameters and another one for both.
> Alternatively, we could add optional KIND=<logical-expr> and
> LEN=<logical-expr> arguments to SAME_TYPE_AS to check equality of KIND
> and/or LEN parameters.  Maybe the arguments should be
> <logical-initialization-expr>.

That's also one of the reasons I want to ask around.  It appears without 
consideration of type parameters, there exists a serious limitation on 
usefulness of SAME_TYPE_AS. I like the idea to add more intrinsics to test 
type and type parameters.  Also there is a problem for adding KIND= and 
LEN= in SAME_TYPE_AS, that is you shouldn't allow user to specify them if 
the two entities are not parameterized.

Cheers,


Jim Xia

RL Fortran Compiler Test
IBM Toronto Lab at 8200 Warden Ave, Markham, On, L6G 1C7
Phone (905) 413-3444  Tie-line 313-3444
email: jimxia at ca.ibm.com
D2/YF7/8200 /MKM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://j3-fortran.org/pipermail/j3/attachments/20080828/f7942ba1/attachment.html