RE: another take on hackers and painters

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

Steve Dekorte wrote:

> > Without reflection or something to replace it, you can't achieve the
> > same result.
>
> Sure you can. Just have your "new and improved" compiler retain the
> mate [meta?] info.

That qualifies as "something to replace reflection" - the meta info would
have to be made available to the eval implementation.

I was writing in answer to your original question: "Java can do reflection,
but can it really do eval?"  The answer I gave involved an add-on library
which makes use of capabilities in Java to implement eval.  This works well
in practice.  Practically speaking, the same thing wouldn't work for C, say,
and that's what I was referring to in my quoted statement above.

> Right, but what's to keep us from using our interpreter on the whole
> program?

You could, but I didn't think we were talking about implementing stand-alone
interpreters.  I was thinking of one of the more common uses of eval, i.e.
evaluating code at runtime, which interacts with other code that's already
running.

For any language in which an eval capability has been implemented as an
extension, rather than built into the language - even in interpreted
implementations - there's likely to be an increased cost for using eval vs.
using the host language directly.  So, typically, you use the host language
where you can, and use eval for the bits that weren't known in advance.

> I don't understand what you mean here. Lots of strongly typed languages
> have eval.

I'm talking about the availability of meta-information, not about strong
typing or lack thereof.  If you have no accessible meta-information about a
data structure, there are serious limits to what you can find out about it
or do with it at runtime.

> The only problem I see with doing it in any language is the restriction
> that it work with precompiled code.

That's not the only problem.  Even if you have an interpreted language
implementation which doesn't offer eval as a built-in capability, you'd have
to implement eval.  The resulting capability would still be constrained in
its interaction with the host program, by the amount of meta-information and
the API which the host language (or program) makes available for querying
and manipulating its data.

For example, imagine an interpreted language implementation that supports
simple data structures, like some versions of BASIC.  These structures would
not necessarily be accessible to code being evaluated by a custom eval.
You'd need a mechanism for instantiating them and accessing their fields by
name (i.e. from strings) at runtime.  Many languages do provide these
capabilities - but not all, by any means.  Java does provide these
capabilites, as part of its reflection mechanism.

> I agree that reflection is required to make that bit possible.
> But that's not a terribly interesting bit to people used to
> languages which don't require precompilation.

I answered your question, I didn't claim the answer was interesting.
Although, I do think the broader issues across languages are interesting,
and that it's worth keeping an open mind about the different ways in which
the same ends can be achieved in different languages - if for no other
reason than to understand why some languages might be successful despite
lacking features some might consider important.

Another answer to your original question, in Java's case, would be that you
could runtime-compile the code in question, and dynamically load the
resulting bytecode, all using built-in capabilities of Java.  Application
servers do this kind of thing all the time.  So there are multiple ways to
achieve a practical 'eval' capability in Java.

Anton