[m-dev.] for review: last call modulo constructors [2/3]

Andrew Bromage bromage at cs.mu.OZ.AU
Wed Jun 24 14:20:57 AEST 1998


G'day all.

David Matthew Overton wrote:

> > Is that the right thing to do for the non-free, non-(ground_or_any) case?
> > Shouldn't you do the same thing recursively in the case of partially
> > instantiated insts?
> 
> My reasoning was that partially instantiated insts should already be
> appropriately aliased by previous calls to abstractly_unify_inst_functor.  E.g:
> 
> 		  % initial inst of X, Y & Z: free(unique)
> 	X = f(Z), % final inst of X: bound(f(alias(IK0, free(alias))))
> 	Y = g(X)  % final inst of Y: bound(g(bound(f(alias(IK0, free(alias))))))
> 
> However, I suppose this may not always be the case.

Correct.  The mode checker is free to _remove_ alias(_) insts if we
leave the scope where the inst is actually aliased.  I'm thinking in
particular of this case:

	( X = f(Z),
	; X = g(Z)
	),
	Y = h(X)

At the end of the disjunction (if Z is local to each disjunct), the inst
of X may well have no alias(_) insts in it since they're local to each
disjunct.

> The only problem with doing a recursive call when unifying Y and
> g(X) is that the liveness information for Z is not available.  If you
> assume Z is dead, the recursive call does nothing.  If you assume Z is
> live, you may get more inst keys than you need.  Andrew, can you tell
> me if this is a problem?

I think the new inst_key renaming strategy will fix this problem.  (Or
at least I hope it will.)

> > > -make_any_inst(free, IsLive, Uniq0, Real, UI, any(Uniq), det, UI) :-
> > > +make_any_inst(free(unique), IsLive, Uniq0, Real, UI, any(Uniq), det, UI) :-
> > >  	unify_uniq(IsLive, Real, det, unique, Uniq0, Uniq).
> > > -make_any_inst(free(T), IsLive, Uniq, Real, UI,
> > > +make_any_inst(free(unique, T), IsLive, Uniq, Real, UI,
> > 
> > Why is that restricted to the free(unique) case?
> 
> I'm not sure about this.

I think it's for code generation reasons, but don't quote me on that.

Cheers,
Andrew Bromage



More information about the developers mailing list