In article <email@example.com>,
Henry Baker <firstname.lastname@example.org> wrote:
>In article <email@example.com>, firstname.lastname@example.org (Paul
>> (Eval should be used
>> very carefully and sparingly in normal apps, because it is
>> slow and tends to confuse compilers so that they can't
>> optimize *other* code as well. You can usually get the
>> effect you want straightforwardly with lambda (for the non
>> Lispers, think of it as "make-procedure"), and it'll be
>> tons faster.
>Of course, you can always do 'apply' of 'compile' of consed stuff instead
Right. (For example, in RScheme and some other schemes, this is how
eval is actually implemented---it just compiles what you give it,
and runs the resulting code immediately.)
>This 'JIT' compilation solves the speed problem.
Not the one I was talking about. A lot of naive users don't understand
that eval is a weird thing to do, and may be rather slow because it
involves either interpretation or compilation. In contrast, lambda
is generally quite fast, because it doesn't actually create new
code, just a new closure to pair code with an environment.
In many scripting apps, this doesn't matter much, but when you start
writing whole programs in a language, it's good to be able to avoid
eval. Using lambda and procedure calling (or macros if necessary)
is usually cleaner and easier anyway.
>(You _do_ have a builtin compiler, don't you?)
Sure. (We don't have an interpreter in the usual sense.)
| Paul R. Wilson, Comp. Sci. Dept., U of Texas @ Austin (email@example.com)
| Papers on memory allocators, garbage collection, memory hierarchies,
| persistence and Scheme interpreters and compilers available via ftp from
| ftp.cs.utexas.edu, in pub/garbage (or http://www.cs.utexas.edu/users/wilson/)