[mercury-users] mode error

[David Overton]

On Wed, Jun 12, 2002 at 01:50:40PM +1000, Michael Day wrote:
> 
> Thought I might share this mode error with the world, seeing as it's so
> impressive.
> 
> What do 'shared' and 'fake' mean?

Let me interpret a portion of this for you:

	list:list_skel((pdf:object))

is a user-defined inst.

	$typed_inst((list:list((pdf:object))), list:list_skel((pdf:object)))

is the same inst with information added about the type of the object in
question, `list:list((pdf:object))' in this case.

	$ground($typed_inst((list:list((pdf:object))),
			list:list_skel((pdf:object))), dead, shared, fake)

is a name that represents the inst obtained by doing a "fake"
unification between the previous inst and `ground'.

The inst `list_skel(object)' has a recursive definition so the inst resulting
from a unification between it and ground is also recursive.  Therefore,
to refer to it finitely, we give it a name (as shown above) which is
referred to using the `$ground(...)' construct.  Note that these "names"
are only used internally by the compiler and in the not-so-helpful error
messages, you can't actually use them in your source code.

The `shared' argument to `$ground' means that the ground inst we are
unifying with is "shared" rather than "unique".  (Internally, the
compiler represents the inst `ground' by `ground(shared)' and the inst
`unique' by `ground(unique)'.)

The `fake' argument means that this is a "fake" unification.  "Fake"
unifications occur when computing the inst of a variable after a call:
the final inst of the argument from the called predicate is unified with
the inst of the variable before the call.  However, in certain cases to
do with unique modes, the inst resulting from this sort of "pretend"
unification needs to be different from the inst that would result from a normal
unification so we need to record that in the name for the `$ground(...)'
inst.

The other argument `dead', also affects the result of the unification.
If the unification were `real' rather than `fake' then the resulting
inst, and whether the unification is legal, would depend on whether both
variables were "live" after the unification or whether at least one of
them is "dead".


Hope that helps clear things up :-)



David
-- 
David Overton      Computer Science and Software Engineering
PhD Student        The University of Melbourne   +61 3 8344 9159
Research Fellow    Monash University (Clayton)   +61 3 9905 5779
--------------------------------------------------------------------------
mercury-users mailing list
post:  mercury-users at cs.mu.oz.au
administrative address: owner-mercury-users at cs.mu.oz.au
unsubscribe: Address: mercury-users-request at cs.mu.oz.au Message: unsubscribe
subscribe:   Address: mercury-users-request at cs.mu.oz.au Message: subscribe
--------------------------------------------------------------------------