Path: utzoo!censor!geac!torsqnt!hybrid!scifi!bywater!uunet!munnari.oz.au!lee
From: lee@munnari.oz.au (Lee Naish)
Newsgroups: comp.lang.prolog
Subject: Re: '->' operator
Message-ID: <6483@munnari.oz.au>
Date: 21 Jan 91 02:22:07 GMT
References: <1471@n_kulcs.cs.kuleuven.ac.be>
Sender: news@cs.mu.oz.au
Reply-To: lee@munmurra.UUCP (Lee Naish)
Organization: Comp Sci, University of Melbourne
Lines: 48

In article <1471@n_kulcs.cs.kuleuven.ac.be> bimbart@kulcs.cs.kuleuven.ac.be (Bart Demoen) writes:
> Perhaps people want to give their opinion about the following:

Ok, here is my 2c worth.
>	should ! in the condition be allowed ?
No, its just too horrible to contemplate.

>	should 1?- X = (true -> write(1)) , call((X ; write(2))) . have the
>	same answer as 2?- X = (true -> write(1)) , (X ; write(2)) .
No.
>	and as 3?- true -> write(1) ; write(2) .
Yes.

I think a variable X in the place of a goal should be the same as
call(X) (it would be even better to force programmers to write
call explicitly; but that would break quite a few programs).  Nothing
inside call should be fiddled with/interpreted until runtime when the
variable bindings are known.  At that time the argument of call should
be treated like a clause body with its own scope for the purpose of
cuts.

Thus, the second goal above is equivalent to
	?- X = (true -> write(1)) , (call(X) ; write(2)).
and the -> cannot be affected by the ;.  With the first goal, the ; is
not interpreted as a disjunction initially because its inside call.  At
runtime, X is instantiated to -> and ; is interpreted as "else".
With the following goal
	?- X = (true -> write(1)), call((Y = X, (Y ; write(2)))).
when call is executed, Y is uninstantiated, so the second occurrence
should have an extra call wrapped around it (like the first goal
above).

Much of the complexity stems from language designers trading
interpretation and compilation simplicity for syntax (eg allowing X
instead of call(X) and using (P->Q;R) instead of if(P,Q,R)).  This tends
continues when explicit quantifiers are introduced.  The syntax is much
nicer if quantified variables are listed explicitly but interpretation
is simpler if all unquantified variables are given explicitly.

One solution to this dilemma is to have a well defined translation from
the user level language to an intermediate language which is suited to
interpretation and other manipulation (with if/3, explicit unquantified
variables and maybe without normal cut).  The user level language can be
considered a shorthand for this language.  More efficient variants of call,
clause etc which use the intermediate language can then be defined.  Its
easy to keep enough information for a reasonable version of listing as well.

	lee