[m-dev.] for review: reordering for existential types [1]

[David Overton]

On Wed, Jun 23, 1999 at 03:26:12PM EST, Simon Taylor wrote:
> 
> > > One other possible problem I noticed is that you moved the code
> > > to convert higher-order pred constants into lambda expressions
> > > from modecheck_unify.m into polymorphism.m. What happens if a
> > > later pass (e.g. deforestation) reruns mode analysis on code which
> > > constructs a higher-order pred constant?
> > 
> > I'm not entirely sure, so I decided that in the interests of safety
> > it is probably best to put that code back in modecheck_unify.m
> > (as well as keeping the copy in polymorphism.m).
> 
> OK. I suspect recompute_instmap_delta_unify on the alias branch
> has the same problem. I'll fix that when I finish off structure reuse.

The job of recompute_instmap_delta is simply to recompute the instmap
deltas, not to change the goal in any way.  E.g. it will not re-order
goals to make them mode correct or introduce unifications for implied
modes.  This suggests that it probably should not be converting higher
order pred constants into lambda expressions either.  If you want to
do that, I think you should rerun mode analysis.


David
-- 
David Overton       Department of Computer Science & Software Engineering
MEngSc Student      The University of Melbourne, Australia
+61 3 9344 9159     http://www.cs.mu.oz.au/~dmo
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------