Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!spool.mu.edu!uunet!munnari.oz.au!goanna!ok From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: '->' operator Message-ID: <4679@goanna.cs.rmit.oz.au> Date: 31 Jan 91 08:25:30 GMT References: <1471@n_kulcs.cs.kuleuven.ac.be> <6483@munnari.oz.au> Organization: Comp Sci, RMIT, Melbourne, Australia Lines: 42 In article , Ray.Nickson@comp.vuw.ac.nz (Ray Nickson) writes: > Would [dropping implicit "call"] it break too many programs? > More than other proposals in the standard would? There isn't any reason whatsoever why leaving implicit "call" out of the standard should break ANY programs. It could remain as a "common extension", just as P(X,Y,Z) as a shorthand for call(P, X, Y, Z) is a not-altogether- unheard-of extension. (The public-domain version of the DEC-10 Prolog parser quietly converts such terms. In practice it was found that such terms were almost always mistakes, so the misfeature was dropped from Quintus Prolog.) What would break programs would be if the standard defined variables occuring where goals are expected to do something *else*. In particular, insisting that such "goals" be rejected at compilation or assertion time, that would break programs. My suggestion, for what it is worth, would be for the standard to leave the effect of goals that are not callable terms implementation defined. That way, call(X) could and should be opaque, as at present, and an implementor whose "..., X, ..." is currently equivalent to the surpassingly bizarre transparent_call(X) wouldn't need to change one little thing. If the standard said that "the behaviour of a non-callable term X as a goal is not defined by this standard, although it is common practice for such goals to behave somewhat like call(X)", then programs using the feature would be no less portable than they are now. > Does someone have an example of where transparent call is actually useful? I second this question. I have never come across any programming situation where transparent_call/1 (as opposed to call/1) would have been useful. It is worth noting that as long as if->then;else is transparent to cuts (so that you can have "conditional cuts" (X=:=0 -> ! ; true)) it's fairly easy to obtain the effect of transparent_call/1. Use the interpreter in "on the treatment of cuts in Prolog source-level tools", and do p(...) :- q(...), interpret(X, HadCut, AfterCut), ( HadCut == true -> !, call(AfterCut) ; true ), r(...). % ^ this cut has p as parent so the implementation of transparent_call/1 is trivial. (It could be added to Quintus Prolog in a couple of days at most. Documentation would be the hardest part, in the absence of any sensible examples of its use.) -- The Marxists have merely _interpreted_ Marxism in various ways; the point, however, is to _change_ it. -- R. Hochhuth.