[mercury-users] functions vs predicates (was Re: State variable problem

Peter Schachte schachte at csse.unimelb.edu.au
Mon Aug 14 17:47:57 AEST 2006

On Mon, Aug 14, 2006 at 05:20:53PM +1000, Mark Brown wrote:
> On 21-Jul-2006, Peter Moulder <Peter.Moulder at infotech.monash.edu.au> wrote:

> > This problem arises with function applications that fail: f \= f is
> > converted to not(f = f), which becomes not(f = Tmp1, f = Tmp2, Tmp1 =
> > Tmp2), where the `f = Tmp' calls are treated like predicate calls:
> > failure of the call means success of the `not' goal, i.e. success of
> > f \= f.
> The explanation for this behaviour is that Mercury follows a simple rule
> for partial (semidet) functions: any atomic formula containing an undefined
> term -- a function application that fails -- is false.  The crucial part is
> that this only applies to _atomic_ formulas.  The goal `f \= f' is not
> atomic, as it is just syntactic sugar for the compound formula `not (f = f)';
> in this case it is the atomic goal `f = f' that is false, and thus fails.

It'd be a shame to give up partial functions.  Do they have problems
other than with negation?  If it's just negation, negation could be
redefined to specify that function calls are executed *outside* the
negation.  Ie, a negated goal would be defined to mean that all the
contained function calls are well-defind (succeed) and the negated
goal fails.

Eg, this example would be implemented as

	f = Tmp1, f = Tmp2, not(Tmp1 = Tmp2)

Peter Schachte              640K should be enough for anyone!
schachte at cs.mu.OZ.AU            -- Bill Gates, 1981 
Phone: +61 3 8344 1338      
mercury-users mailing list
Post messages to:       mercury-users at csse.unimelb.edu.au
Administrative Queries: owner-mercury-users at csse.unimelb.edu.au
Subscriptions:          mercury-users-request at csse.unimelb.edu.au

More information about the users mailing list