Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!otter.hpl.hp.com!otter!sfk From: sfk@otter.hpl.hp.com (Steve Knight) Newsgroups: comp.lang.misc Subject: Re: A comment on language wars. Message-ID: <2400032@otter.hpl.hp.com> Date: 10 Mar 91 12:25:02 GMT References: Organization: Hewlett-Packard Laboratories, Bristol, UK. Lines: 35 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