🚀 go-pugleaf

In article <365@aiva.ed.ac.uk>, jeff@aiva.ed.ac.uk (Jeff Dalton) writes:
> In article <841@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes:
> >Yes, it *is* theoretically impossible to write a correct automatic conversion
> >program from Lisp to assembler.  You have to have an interpreter as well.
> >Why?  Because you can construct code on the fly and execute it.

> I take your point, Richard, but it's worth pointing out that you don't
> need an interpreter per se: you can just keep the translator around.

I regard keeping the translator around as just another way of implementing
an interpreter.  (I wish someone would implement a Brown-et-al-style
"throw-away-compiler" for Prolog and get us some measurements.)  The point
is that you need a non-trivial chunk of code which in some sense defines the
semantics of the _OLD_ language.

> It's interesting that call/1 in Prolog is basically an EVAL, while
> Lisp has EVAL but also a less troublesome notion in APPLY.  

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 point is that call(','(write(a)), write(b)) ends up calling write(a)
and write(b), not because call/2 does anything special, but because (A,B)
calls A and B.  It is as if you did
	(APPLY #'(LAMBDA (X Y) (AND (EVAL X) (EVAL Y)))
	    '(PRINT 'a) '(PRINT 'b) '())
in Lisp.

There is a splendid little article in the April 1988 issue of SigPlan
Notices:
	"The Role of the Language Standards Committee".
I particularly like his point 3.  (Which amongst other things suggests that
a standard is not the place for _MY_ pet ideas either.)