(j3.2006) more on J32031 equivalence of circular types
Van Snyder
Van.Snyder at jpl.nasa.gov
Thu Aug 21 16:23:48 EDT 2008
On Wed, 2008-08-20 at 18:46 -0700, Van Snyder wrote:
> On Wed, 2008-08-20 at 15:19 -0700, Aleksandar Donev wrote:
> > On Wednesday 20 August 2008 15:15, Bill Long wrote:
> > > I guess I don't see what part of the answer is not obvious here. What
> > > part of f03:4.5.1.3 is ambiguous in the case?
> >
> > TYPE(T), POINTER :: NEXT => NULL()
> >
> > Does this component in type T in module FOO have the same type as that in
> > module BAR? If you know the answer, you've already answered the question you
> > are trying to answer. You get into an infinite loop that you must terminate
> > somehow.
>
> The answer depends upon whether you start by assuming the types are
> equivalent and try to prove they're not, or start by assuming the types
> are different and try to prove they're equivalent.
>
> In the first case, you assume the types of A and B are equivalent. Then
> you start doing a simultaneous recursive traversal of both type systems'
> graphs (type systems in the case of recursive types involving more than
> one type). When you arrive at types you've visited, you say "Aha! I've
> been here, so they must be the same!" If you arrive at anything
> different in the traversals, you quit and say "No!" If you finish
> traversing the graphs by visiting every vertex without saying "No!", you
> quit and say "Yes!"
I don't think you have any choice but to say "Aha! I've been here so
they must be the same" when the simultaneous traversals arrive at
previously-visited types. If they were different, the algorithm would
already have quit with a "No" answer.
> Mike gets into an infinite loop by assuming the types of A and B are not
> equivalent, so when he arrives at TYPE(T), POINTER :: NEXT he knows he's
> been there, but not that the T's are equivalent, so he dives into their
> graphs.
>
More information about the J3
mailing list