🚀 go-pugleaf

In article <385@aiva.ed.ac.uk>, jeff@aiva.ed.ac.uk (Jeff Dalton) writes:
> In article <365@aiva.ed.ac.uk>, jeff@aiva.ed.ac.uk (Jeff Dalton) writes:
> - It's interesting that call/1 in Prolog is basically an EVAL, while
> - Lisp has EVAL but also a less troublesome notion in APPLY.  
> In article <903@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A.
> O'Keefe) writes:
> + Actually, call/1 in Prolog is a pretty straightforward APPLY.  (There is
> + a family of call/N things each adding N-1 extra arguments.)  The problem
> + is that ','/2 and so on are FEXPRs.  (Is everyone nicely confused now?)

> The difference between Prolog and Lisp is that in Prolog just saying
>      call(X).
> takes some "source code representation" (the value of X) and
> interprets it as code while in Scheme-like Lisps
>      (apply f ...)
> doesn't.  The value of F is a procedure, not the name of one.

There are two differences between EVAL and APPLY
(1) EVAL evaluates the arguments of its argument, APPLY does not.
    In this respect, call/1 resembles APPLY, not EVAL.  call/1 as such
    does not do any interpretation other than to locate the predicate
    which is to be called.
(2) EVAL is given (a form in which there occurs) the _name_ of a function,
    not the function itself, APPLY is given a function pointer/closure &c.
    In this respect call/1 resembles EVAL, not APPLY.  There is no Prolog
    object which "directly" represents a predicate.

I have always regarded the essential feature of EVAL as being (1), and
have regarded (2) as a detail of implementation, so I understood "is
basically an EVAL" to mean "is like an interpreter which is responsible
for evaluating sub-forms".  That is what is false.  Jeff Dalton is quite
right about (2), and as he points out, you _do_ have to work a bit to
make a module system and call/1 work together.  If Prolog were typed,
with the void/N type constructor as Alan Mycroft suggested, it would be
possible to have a version of call/1 which resembled APPLY in both respects.