RE: another take on hackers and painters

["Anton van Straaten" <address@hidden>]

Steve Dekorte wrote:

> For simple expressions, I agree. But the general case might be
> trickier than it sounds. For example, could you add/remove ivars
> from a class that other classes inherit from at runtime? (Does
> Java compile references to ivars as pointer offsets causing a
> fragile base class problem?) Can you change existing methods at
> runtime? What if the method argument types change? Can you change
> a type definition at runtime? What happens to the rest of the code
> in the system that depends on the old type?

All of that is completely orthogonal to the question of whether a language
can support an eval capability.  If the host language allows the operations
you've listed, then implementing eval by compiling to bytecode, and then
loading that bytecode, should also support those operations.  The mechanism
is not limited to simple expressions.  As with eval in a language like
Scheme, it's part of the infrastructure Java uses for running all code.

In fact, Java's design in this area seems like The Right Thing, which any
bytecode-based interpreter ought to consider using.  In any language based
on a bytecode interpreter that supports an eval, the eval operation is
likely to contain a compile phase which compiles to bytecode.  Java simply
separates this compile phase out and allows it to be invoked explicitly,
which provides more flexibility.

You can see this flexibility being used in practice: as I mentioned,
application servers routinely compile Java source code, often generated from
templates, and load the resulting bytecode into heavily-utilized running
systems.  This is a traditional case, where a Java source file is compiled
to a Java class file (bytecode), and the class file is loaded from the
filesystem.  Alternatively, you have Per Bothner's example which Vadim
Nasardinov pointed out, where bytecode is generated directly from a source
string and loaded without touching the file system, thus implementing an
eval that works very much like it does in traditional interpreters.

Anton