(j3.2006) derived types with type parameters are different

[Lawrie Schonfelder]

The only reason qua Fortran, ignoring any interlanguage issues, that I can think of is to enable a
parameterised derived type object to be employed in a storage associated context.  For instance,
someone might declare a common block with the same storage layout as a sequence derived type and
equivalence them, god knows why! In the presence of parameters of the LEN variety this could prove
to be problematic.

I have never seen a convincing case for declaring the same (equivalent) type in multiple places even
if SEQUENCE is used. However, given that we have got it, we should make it at least implementable. I
think that what was done in f03 was a mistake. We could correct that at this point. I would suggest
that type equivalence for parameterised sequence types requires lexical identity. A processor would
be permitted but not required to diagnose any deviation from this. Any implementers who were
prepared to have a large chunk of MAPLE included in their compilers so as to prove mathematical
equivalence of expressions could be more relaxed but this would not be guaranteed for portability.

Such a change makes minimal reduction in utility and breaks no existing implementations (there are
none?) nor any applications (likewise?). Standardisers can make mistakes too! Banning SEQUENCE with
parameterised type, as I originally proposed, would have been better but that now would be a change
too far.

--
Lawrie Schonfelder
Wirral, UK

> -----Original Message-----
> From: j3-bounces at j3-fortran.org [mailto:j3-bounces at j3-fortran.org]On
> Behalf Of Michael Ingrassia
> Sent: 30 July 2008 19:03
> To: j3 at j3-fortran.org
> Subject: Re: (j3.2006) derived types with type parameters are different
>
>
> >If we take the attitude that, 5 years after the fact, it's OK to remove
> >some intentionally included feature ... then what level of
> >confidence does any vendor have
>
> Absolutely, I agree with you here.
>
> The trouble here in this specific case
> is that even if we agree that
> "parameterized derived types with SEQUENCE attributes" was a feature included
> intentionally, in some sense, it's not clear that 'qua feature' it
> has any particular meaning.
>
> If we can clarify exactly what the meaning was/is, we will be better off.
> If there is no particular meaning, it hardly matters that we protect
> the standards process if we can't also protect the standard.
>
> Can't  the basic integrity of the standards process also be
> hurt by agreeing only on syntax?
>
> If users will have codes with parameterized derived types with
> SEQUENCE attributes, then I hear you arguing that the standard should
> guarantee that all vendors shall accept those codes.
>
> Suppose a vendor accepts the code but treats SEQUENCE as a noop in the
> presence of type parameters.
> Has the standard been subverted?  What does the user expect by adding
> SEQUENCE?  What does the standard guarantee to the user who adds SEQUENCE ?
>
> 	--Michael I.
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>