Related articles |
---|
[10 earlier articles] |
Re: Why is compiled basic slower than C? (Basic is the future) macrakis@osf.org (1992-08-17) |
Re: Why is compiled basic slower than C? (Basic is the future) fjh@munta.cs.mu.OZ.AU (1992-08-18) |
Re: Why is compiled basic slower than C? (Basic is the future) imp@Solbourne.COM (1992-08-18) |
Re: Why is compiled basic slower than C? (Basic is the future) burley@geech.gnu.ai.mit.edu (1992-08-18) |
Re: Why is compiled basic slower than C? (Basic is the future) pdg@crosfield.co.uk (1992-08-19) |
Re: Why is compiled basic slower than C? (Basic is the future) pk@cs.tut.fi (1992-08-21) |
Re: Why is compiled basic slower than C? (Basic is the future) robert@metropolis.com (1992-08-25) |
Newsgroups: | comp.compilers |
From: | robert@metropolis.com (Robert Munyer) |
Organization: | Metropolis Software, Inc. |
Date: | Tue, 25 Aug 1992 08:29:01 GMT |
References: | 92-08-042 92-08-095 |
Keywords: | interpreter, performance, Lisp |
macrakis@osf.org (Stavros Macrakis) writes:
> [...] There are a few cases where Lisp code generates code on the fly,
> then executes it. This is handled by having an interpreter loaded along
> with the compiled code [...]
... or by having a COMPILER loaded along with the compiled code ...
Also, much of the kind of programming that people used to do by generating
and executing code on the fly, is now done instead by using functional
programming and closures. In other words, using "lambda" instead of "eval".
Robert Munyer
robert@metropolis.com
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.