drl@vuse.vanderbilt.EDU (David R. Linn) (07/18/88)
Date: Tue, 12 Jul 88 13:46 EDT From: David R. Linn <drl@vuse.vanderbilt.edu> To: ailist@ai.ai.mit.edu Subject: LISP Implementation: Clarification of the Question "What??? Oh, I see; we use the term 'interpreter' to mean different things." From the initial response to my question about noninterpretive LISP implementations, it appears obvious that I misphrased the question. Perhaps a bit of context will help. My project involved porting the Franz LISP system (38.87)to two nonBSD environments. The core of the FL system is a C and assembly language program called _rawlisp_. This program is, by my definition, a LISP interpreter but it supplies more than just the evaluation service. It supplies the memory management, i/o primitives, stack/memory management and basic LISP environment maintenance. All FL programs, whether interpreted or compiled, run within the environment provided by the interpreter (usually by _lisp_, a version of _rawlisp_ whose environment has been heavily augmented by loading (compiled) LISP code). Perhaps a better name for what I call a "LISP interpreter" would be a "LISP environmental support program" (LISP ESP). Now, hopefully, I can restate my quesion in clearer terms: Does anyone know of a LISP implmentation that does not support the language by loading (possibly compiled) LISP code into a LISP ESP in order to execute it? I disqualify setups like the FL autorun facility since these implicitly involve loading code into a LISP ESP and preloaded systems like the FL LISP compiler _liszt_. Although it would be difficult, I can see that it might be possible to support LISP like C: compile the source to object code and link the object with a startup routine and (probably hefty) library. Again, please reply directly to me and I will summarize the responses. David David Linn - drl@vuse.vanderbilt.edu (should now agree with header)