Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!quintus!ok From: ok@quintus.UUCP (Richard A. O'Keefe) Newsgroups: comp.lang.prolog Subject: Re: compatibility/elegance & *theory* Message-ID: <919@cresswell.quintus.UUCP> Date: 30 Apr 88 02:37:41 GMT References: <136@vor.esosun.UUCP> <841@cresswell.quintus.UUCP> <365@aiva.ed.ac.uk> <383@aiva.ed.ac.uk> Organization: Quintus Computer Systems, Mountain View, CA Lines: 43 In article <383@aiva.ed.ac.uk>, richard@aiva.ed.ac.uk (Richard Tobin) writes: > Is this really true? Isn't it the case that in all reasonable prologs > call/1 *is* a simple interpreter, with the result that (in particular) > cut works reasonably? Yes it is true, and no it is not the case that call/1 *is* an interpreter. Be careful to distinguish what something _IS_ from how it is _implemented_. Let me sketch a different implementation: call(Goal) :- callable(Goal), locate_procedure_record(Goal, Proc), !, unpack_goal_and_jump(Goal, Proc). call(Goal) :- callable(Goal), !, . call(Goal) :- . So, for example, call(append(A,B,C)) is basically an indirect jump to the (presumably compiled) code for append/3; this jump having occurred nothing further takes place that could be called "interpretation". Accompanying this would be definitions like ','(A,B) :- label(ChoicePoint), interpret((A,B), ChoicePoint). ';'(A,B) :- label(ChoicePoint), interpret((A;B), ChoicePoint). This is what I meant by saying that __call__ is like EVAL, but that __,__ and __;__ and so on are FEXPRs. It is not that 'call' interprets anything, but that if you call ','/2 IT will do certain things. (Think of the compiler as doing partial execution.) > Are you being disingenuous here, or have I just eaten too much microwave > popcorn? I'm afraid it must be the latter. Try cooking it first (:-).