(j3.2006) About extending abstract types with deferred bindings

[Clune, Thomas L. GSFC-6101]

Van,

Even the bindings that are not deferred may themselves refer to deferred bindings.   Quite common in practice actually.  Thus it is unsafe to invoke _any_ bindings on the abstract component.   (And to anticipate Malcolm:  Not only is it unsafe, it is not allowed.)

I do not think there is any significant weakening of the constraints in this direction that are workable.  I?ve pushed gently in this direction in various private conversations.    Gradually, I understood why I did not really want to do that.   :-)

Cheers,

- Tom



> On Sep 9, 2016, at 3:19 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
> 
> On Fri, 2016-09-09 at 10:47 +0900, Cohen Malcolm wrote:
>> If one rashly imagines that we got some of this stuff right, a simple
>> search for "abstract type" turns up several obvious constraints. 
> 
> I had rashly assumed we got this right, so I looked for a relevant
> constraint in Clause 15, not Clause 9.
> 
> Constraint C911 exists, but it's in the wrong place.  It's a too-big
> hammer.  It prevents too much.  In particular, it prevents accessing the
> parent component of an object of an extension type of an abstract type,
> as a whole data object.  The parent component is a perfectly good
> object.  The only problem with objects of abstract type is invoking
> deferred procedure bindings, which we could have successfully
> accomplished without preventing data access if we had gotten this right.
> C911 could instead be C1535a, mutatis mutandis:
> 
> C1535a (R1523) If the rightmost <part-name> of <data-ref> is of abstract
>       type, <data-ref> shall be polymorphic.
> 
> This indirectly prevents trying to invoke a deferred procedure binding
> using an object of abstract type, even using the parent component of an
> object of an extension type of an abstract type (because the parent
> component isn't polymorphic), but it doesn't prevent accessing the
> object as a data object.
> 
> This is still indirect, and a too-big hammer, because it also prevents
> invoking bindings that aren't deferred (which is what it ought to
> address directly instead of indirectly), so an even better (i.e., more
> precise) constraint would be:
> 
> C1535a (R1523) If the rightmost <part-name> of <data-ref> is of abstract
>       type and <data-ref> is not polymorphic, the <binding-name> shall not
>       have the DEFERRED <binding-attr>.
> 
> This is a bit too wordy (and so is C911), in light of 9.4.2p4:
> 
>        "The type and type parameters, if any, of a <data-ref> are those
>        of the rightmost part name."
> 
> We also don't need to mention abstract type, since a nonabstract type
> doesn't have deferred bindings.  So even better would be:
> 
> C1535a (R1523) If <data-ref> is not polymorphic, the <binding-name>
>       shall not have the DEFERRED <binding-attr>.
> 
> This only prevents trying to invoke deferred procedure bindings, which
> is all we really need to accomplish.  It doesn't prevent invoking
> non-deferred bindings using the parent component of an object of an
> extension type of an abstract type, which would occassionally be useful,
> and it doesn't prevent accessing the parent component as a data object.
> 
> So, my rash assumption was wrong.  We didn't get this right.  I assume
> we can't repair this blunder now.
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3