[m-rev.] diff: allow var-functor unifications for vars with inst `any'.

Fergus Henderson fjh at cs.mu.OZ.AU
Mon May 13 17:10:00 AEST 2002


On 13-May-2002, David Overton <dmo at cs.mu.OZ.AU> wrote:
> On Thu, May 09, 2002 at 07:49:24PM +1000, Fergus Henderson wrote:
> > On 09-May-2002, David Overton <dmo at cs.mu.OZ.AU> wrote:
> > > Allow var-functor unifications where the variable has inst `any'.
> > >
> > > compiler/inst_util.m:
> > > 	Handle `any' insts in abstractly_unify_inst_functor.
> > 
> > I don't think this is sufficient, since handling var-functor unifications
> > where the variable has inst `any' would require not just changes to the
> > mode analysis algorithm, but also changes to code generation, since the
> > current code generator doesn't know how to implement such unifications.
> > 
> > Unless you are assuming that any concrete type which has inst `any' must
> > actually be ground... I guess that could work, but if so, that assumption
> > should be clearly documented somewhere, including in particular the
> > places in mode analysis and/or code generation which rely on it.
> 
> This assumption is documented at the top of inst_util.m,

Where?

It is documented that `ground' and `any' must have the same representation,
but that is *not* the same thing as saying that a variable whose inst is
`any' must actually be ground.

In particular, for the --reserve-tag grades, there is tag reserved for
representing unbound variables, and the code for unifying a variable with
inst `any' with a functor should check to see whether that variable
is bound.  Currently the code that we generate doesn't do that.

It's better to report a compile error rather than generating incorrect
code, so I'm still not convinced that this change is a good idea...

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
mercury-reviews mailing list
post:  mercury-reviews at cs.mu.oz.au
administrative address: owner-mercury-reviews at cs.mu.oz.au
unsubscribe: Address: mercury-reviews-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-reviews-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------



More information about the reviews mailing list