🚀 go-pugleaf

Peter writes:
> I suspect that if you remove the explicit interpreter and examined the
> remaining language, I will still be able to point to a part of the
> language and say "that's the interpreter!". That will be the part that
> takes a closure and executes it. In Forth terms, Lisp has an outer and
> an inner interpreter.

This claim seems to elevate a common implementation practice, that of having 
different run-time formats for procedures built at compile-time and 
procedure built at run-time, to the level of a common "principle".

Although there are many such systems, there are also counter-examples.  One
I am familiar with is the Poplog system, which supports first-class
procedures (in the usual, non-Bernsteinian sense) but has no "interpreted"
form.  Closures are blocks of machine code and are created (by the system)
in the same shape and form as other procedures.  There is no difference
between the invocation of an ordinary procedure and a closure.

The closest I can come to seeing an "interpreter" in the run-time system is
that when procedures are passed as parameters, it is actually pointers to
them that are passed around.  So executing such a procedure involves 
dereferencing a pointer.

The "trick" to avoiding the necessity of an interpreter for a procedure in
a dynamically-typed system is as follows.  Since procedures created at
run-time reside (typically) in the heap, all heap bookkeeping information
(such as type and length) must be placed so as not to interfere with the
procedure or closure format.  In Poplog, this is done by the simple 
expedient of placing it "before" the procedure pointer.  This is just as
suitable for strongly typed languages (but they present slightly fewer
problems).  

I hope this helps to clarify this rather muddy topic.

Steve