On 18/07/07, John Lam (CLR) <jflam / microsoft.com> wrote:
> > Can you explain this? The way I see this, the piece of code that does
> > the actual aliasing is yours, and this piece of code is unaffected by
> > aliasing alias_method or any other dirty trick, so a check in that
> > piece of code should work perfectly for detecting if eval and consorts
> > get aliased. Of course, this is a run time check and not a compile
> > time check, but I think this is what Brent is proposing. Besides,
> > there is no way you can check this at compile time because aliasing
> > eval and consorts can be done in any single eval anywhere in the code.
>
> What do you do about a method that was changed via eval that is already compiled and partially executed on your return call stack?

I was talking about the detection part only (seems I need to work on
my quoting.)

But changing a partially executed method seems to be the big stumbling
block. HotSpot does manage this feat, so it can be done. It puts its
limitations on the optimizations that can be done, and I expect these
limitations could be worse for Ruby with its eval, but that's the
nature of the beast.

Of the 7 methods named by Charles, eval is the most problematic
because it needs all variables to still be present to create a dynamic
scope if needed (at least in a naive version). An unexpected call to
local_variables requires metadata about statically defined variables
and a reference to a dynamic scope for the dynamically defined
variables. Support for block_given?/iterator? really only needs one
bit. If public/private/protected are aliased or overridden, and
visibility is different from what static analysis determined, then
checks need to be prepended to the methods for which visibility
changed. But this is all rather easy to implement, and it impedes
optimization only in a minimal way. The real bad guy is eval.

I've been toying with alternatives to eval that are more susceptible
to static analysis, and ideas are far from ripe, but one aspect may be
of interest to this discussion. The idea would be to replace the eval
method by a %e construct, a bit like what %x does for shell execution.
I know several people will be opposed to this idea because they don't
like these kind of constructs, but it would make the presence of eval
manifest. And it does not introduce new keywords. But I'd expect some
heavy opposition, also because this change would break much more code
than making eval a keyword.

Peter