Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!nickson
From: Ray.Nickson@comp.vuw.ac.nz (Ray Nickson)
Newsgroups: comp.lang.prolog
Subject: Re: '->' operator
Message-ID: 
Date: 22 Jan 91 00:37:10 GMT
References: <1471@n_kulcs.cs.kuleuven.ac.be> <6483@munnari.oz.au>
Sender: news@comp.vuw.ac.nz (News Admin)
Organization: Victoria University of Wellington, Wellington, New Zealand
Lines: 37
Nntp-Posting-Host: circa.comp.vuw.ac.nz
In-Reply-To: lee@munnari.oz.au's message of 21 Jan 91 02:22:07 GMT

In article <6483@munnari.oz.au> lee@munnari.oz.au (Lee Naish) writes:

   (it would be even better to force programmers to write
   call explicitly; but that would break quite a few programs)

Would it break too many programs?  More than other proposals in the
standard would?  Lots of complexity in the draft draft standard I
looked at (WG17 N64) arose from allowing this feature; I'd prefer it
to be dropped.  For one thing, programmers using metacalls should at
least be aware that they are no longer writing logic; when call/1 is
not written explicitly, this may not be obvious.

My opinions on the if-then-else issue: (I use ->/2 and ;/2 a lot,
although I'd prefer a more sensible syntax).

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:

   >	should ! in the condition be allowed ?
Yes; I see no reason why not (though I have never implemented such a
thing).  The cut should apply just to the condition.  In fact, I'd
like implementations (optionally) give a warning on potential
indeterminacy in the condition, then (Cond -> Then ; Else) could be
given up in favour of if((Cond,!), Then, Else), where if/3 explores
all solutions to Cond (as in SICStus).

   >	should 1?- X = (true -> write(1)) , call((X ; write(2))) . have the
   >	same answer as 2?- X = (true -> write(1)) , (X ; write(2)) .
   >	and as 3?- true -> write(1) ; write(2) .  
If implicit metacalls are allowed, it seems more natural to treat X as
if its binding at call time were explictly written in place; this
would make X transparent to cut, and the answer to the above questions
yes.  This makes X different from call(X), and like
transparent_call(X), although I've never needed a transparent call
anyway.  These appears to be what SICStus does, despite the manual
saying X and call(X) are identical.  Does someone have an example of
where transparent call is actually useful?