[m-dev.] failing test cases

[Fergus Henderson]

On 23-Oct-2000, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> `any' insts (fjh)
> The problem here was exposed by David Overton's changes to add support for
> polymorphic insts, but the real cause is probably that the output of some
> of the compiler passes is not mode-correct.
> 	extras/clpr/samples/tranny.c
> 	extras/clpr/trailed_update/var.c

I had a look at this one.  The problem is due to the way I've handled
the `in(any), in(any)' mode of unification.  Currently such
unifications are allowed, and result in calls to unify/2 or to the
type-specific unification procedure for that type, which both have
mode `in, in', not mode `in(any), in(any)'.  The idea is that for
types which support `any' insts, the type-specific unification
procedure should allow the arguments to have inst `any'.  But the
compiler doesn't know which types support `any' insts, so this is not
reflected in the modes for the type-specific unification procedures.
As a result, once complicated unifications are converted into calls to
unify/2 or to type-specific unification procedures, the HLDS is not
mode correct.

One possible fix would be to explicit mark types which support `any'
insts with some special syntax in the type declaration.  Then the
compiler could give the unification procedure for such types mode
`in(any), in(any)' rather than `in, in'.  We don't want to do that in
the general case, though, because that would break code using
user-defined equality predicates that have mode `in, in'.

The special syntax could be

	:- dynamically_moded type foo ---> ...

or perhaps

	:- type foo ---> ...
		where init_any is <PredName>.

The latter would also help avoid the current hack where the name
`init_any' is treated specially. (It's the procedure to initialize
the representation of an unbound variable with inst `any').

If we want to support polymorphic use of `any' insts, which we should,
then we'd also need to add a `in(any), in(any)' mode for unify/2.
Note that this is safe even for types that don't support `any' insts,
e.g. `int', since there's no way to create a variable of such types
with inst `any'.

Unfortunately none of this would be trivial to implement, so in the
short term the easiest fix is to just turn off the error check which
was causing the failure.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
                                    |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.
--------------------------------------------------------------------------
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
--------------------------------------------------------------------------