|The melting ice technology (1): compilers & interpreters email@example.com (1994-05-09)|
|The melting ice technology (2): levels firstname.lastname@example.org (1994-05-09)|
|Re: The melting ice technology (2): levels email@example.com (1994-05-12)|
|Re: The melting ice technology (2): levels firstname.lastname@example.org (1994-05-13)|
|Re: The melting ice technology (2): levels email@example.com (1994-05-13)|
|Re: The melting ice technology (2): levels firstname.lastname@example.org (1994-05-14)|
|Re: The melting ice technology (2): levels email@example.com (1994-05-16)|
|From:||firstname.lastname@example.org (Lawrence G. Mayka)|
|Keywords:||interpreter, Eiffel, Lisp|
|Organization:||AT&T Bell Laboratories, Naperville, Illinois, USA|
|Date:||Sat, 14 May 1994 19:17:45 GMT|
email@example.com (Michael Coffin) writes:
[re Bertrand Meyer's articles on compilation and interpretation]
I don't think there's any reason to be defensive about this, by the way.
Many very useful languages---Scheme, Lisp, Elisp, Perl, Icon, and Awk, for
example---are usually implemented using the same basic approach: an
interpreter with compiled versions of the time-critical pieces to avoid
most of the performance penalty. Although some of them allow compilation
of code as well as interpretation (Icon and the Hobbit comiler for Scheme,
for example), none of them I'm familiar with seem to integrate
interpretation and compilation as nicely as Melting Ice.
Actually, most commercial and free-of-charge Common Lisp implementations
nowadays compile down to machine instructions, plus calls to the run-time
library as necessary. Most also include an interpreter, for the sake of
top-level interaction more than anything else; and of course compiled and
interpreted code can freely reference each other.
But this all only demonstrates that the principle of offering more
than one space/run-speed/compilation-speed tradeoff is a sound one.
Lawrence G. Mayka
AT&T Bell Laboratories
Return to the
Search the comp.compilers archives again.