Deferred TBPs
Jared Ahern
Are deferred type-bound procedures (from an abstract type) *required*
to be replaced by actual TBPs in non-abstract child types? I had
originally thought so, but now I am unclear as to whether this is
required, or if the deferred interface just specifies what the actual
interface must be *if* it is present.
Thanks!
Jared
robert....@sun.com
I know what the answer is supposed to be, but I can
see how the statement in the Fortran 2003 standard
that supports the answer could be read to mean
something else. The statement from page 57, line 22
of the Fortran 2003 standard is
A deferred binding shall appear only in the
definition of an abstract type.
The statement means that if any of the bindings of a
derived type are deferred bindings, the type must be
an abstract type.
Bob Corbett
Jared Ahern
> derived type are deferred bindings, the type must be
> an abstract type.
Well, that might answer my question, but let me elaborate to make it
clear. Say I had an abstract type "Person", which had a deferred
procedure "Talk", which has an associated abstract interface. I now
make a new non-abstract type, "Lawyer", that extends "Person".
Clearly, the definition of "Lawyer" cannot contain deferred bindings
(IAW the response above). However, do I have to implement an actual
"Talk_Lawyer" procedure and tie it to "Talk" in the definition of
"Lawyer", or is this optional? If I do not, does this mean that
"Lawyer" now has a deferred binding? (And would a grandchild type
also have the deferred binding available to it?)
I have found that with ifort 11.1, this is not required: an abstract
parent type can contain a deferred binding that a non-abstract child
type simply ignores. But I don't understand whether that's allowed by
the standard or not, even with the above quote, because I am unclear
as to whether the deferred binding is actually part of the child type
if it has been ignored.
It would seem to me that a non-abstract type should have to implement
actual procedures to fill in for every deferred procedure in any
parent type. Then the compiler is sure that an actual binding is
available for that type. Since I have not found this to be the case,
I wanted to check...
robert....@sun.com
Note 4.50 on page 60 of the Fortran 2003 standard states
A deferred binding (4.5.4) defers the implementation of
a type-bound procedure to extensions of the type; it
may appear only in an abstract type. The dynamic type
of an object cannot be abstract; therefore, a deferred
binding cannot be invoked. An extension of an abstract
type need not be abstract if it has no deferred bindings.
The restriction in the Fortran standard is not a constraint,
so compilers are not required to diagnose violations of the
restriction.
Bob Corbett
Richard Maine
> Note 4.50 on page 60 of the Fortran 2003 standard states
>
> A deferred binding (4.5.4) defers the implementation of
> a type-bound procedure to extensions of the type; it
> may appear only in an abstract type. The dynamic type
> of an object cannot be abstract; therefore, a deferred
> binding cannot be invoked. An extension of an abstract
> type need not be abstract if it has no deferred bindings.
>
> The restriction in the Fortran standard is not a constraint,
> so compilers are not required to diagnose violations of the
> restriction.
And indeed, as a Note, it would not even be normative. ("Normative" is
standard-speak for "the real stuff". Things that are not normative are
supposed to do things like help explain the normative material. I know
you are aware of this Bob, but other readers might not be).
In this case, I'd say that the Note does clarify a possible ambiguity
that I see in the previously quoted
"A deferred binding shall appear only in the
definition of an abstract type."
I find it quite easy to read that restriction as purely syntactic, which
would mean that you can't syntactically put a deferred binding in the
definition of a non-abstract (I suppose that would be "concrete", though
I don't recall that the standard uses the term) type, but you might be
able to inherit one.
In my opinion, far too much of the standard refers to syntax. There are
people who like it that way because it allows them to more directly see
what code is allowed. But I think that it is an error-prone way to
express much of the standard; examples of such past errors exist (such
as restrictions meant to apply to the SAVE attribute, but written in
such a way as to miss multiple syntax alternatives that can give that
attribute; the first attempt at correction got one alternative, but
still missed others).
Anyway, I would say that the "An extension of an abstract type need not
be abstract if it has no deferred bindings" in the above Note makes it
clear that the intent is that a non-abstract type can't have deferred
bindings by inheriting them either.
--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain
Jared Ahern
hopefully they will decide to diagnose this.
Jared
Damian
I apologize for being dense, but I'm still having a hard time
understanding the answer to the original question. Does an extended
type have to implement its parent's deferred bindings or can it ignore
them? Can I get a yes or no? (I'm sorry if that sounds rude. I'm not
intending to come across that way -- just trying to understand since I
encountered the same behavior with the Intel Fortran 11.1, had the
same question, and presumed the same answer, i.e. that it's a bug).
Damian
Richard Maine
> On Jul 24, 6:55 pm, nos...@see.signature (Richard Maine) wrote:
> > Anyway, I would say that the "An extension of an abstract type need not
> > be abstract if it has no deferred bindings" in the above Note makes it
> > clear that the intent is that a non-abstract type can't have deferred
> > bindings by inheriting them either.
> I'm still having a hard time
> understanding the answer to the original question. Does an extended
> type have to implement its parent's deferred bindings or can it ignore
> them? Can I get a yes or no?
While there is a certain temptation to answer with just "yes", leaving
it ambiguous which of the two opposite questions above it applies to,
I'll try to be more helpful than that. :-)
No, you can't get a yes or no because the answer is "it depends". But
the dependency is pretty simple, namely:
If the extended type is also abstract, then no, the extended type does
not have to implement the parent's deferred bindings (and yes, it can
ignore them).
If the extended type is nonabstract, then yes, the extended type has to
implement the parent's deferred bindings (and no, it cannot ignore
them).
> I encountered the same behavior with the Intel Fortran 11.1, had the same
> question, and presumed the same answer, i.e. that it's a bug
A bug in what? Violating the above-noted requirements would be a bug in
the code. But as Robert pointed out, failing to diagnose the error would
not be a bug in the compiler; the standard does not require such
diagnosis. (I'm not sure why not, as it looks like the kind of things
that ought to be compile-time diagnosable and thus is typically made a
constraint in the standard. But I could have missed something, or the
standard could just have overlooked the possibility of making it a
constraint.)
Failing to diagnose the error could well be considered a quality of
implementation shortcoming, but it isn't a bug in standard conformance.
Damian
Excellent answer -- thanks!
Damian