[ruby-core:98592] [Ruby master Feature#16924] instance_eval equivalent for RubyVM::InstructionSequence

Issue #16924 has been reported by Wuerfel21 (Ada Gottenstr舩er).

----------------------------------------
Feature #16924: instance_eval equivalent for RubyVM::InstructionSequence
https://bugs.ruby-lang.org/issues/16924

* Author: Wuerfel21 (Ada Gottenstr舩er)
* Status: Open
* Priority: Normal
----------------------------------------
# Abstract
Proposal to expose the ability to evaluate precompiled ISEQs in non-toplevel contexts.
# Background
A common pattern used for certain kinds of DSL is to instance_eval entire files, like this:
```ruby
___dsl_object.instance_eval(File.read(___path),___path,0)
```
This has certain advantages and disadvantages over other methods of executing DSL code (mainly that the global namespace is not being polluted by either the DSL itself or the code running in the DSL). I find it very useful.

Ruby exposes the RubyVM::InstructionSequence API, allowing caching of parsing/compilation steps to speed up execution. However, the resulting code can only be evaluated at the top level, disallowing it's use with DSLs designed to be instance_eval'd.

# Proposal
Add a `RubyVM::InstructionSequence#eval_in_instance` method that could be used to replace
```ruby
___dsl_object.instance_eval(File.read(___path),___path,0)
```
with
```ruby
iseq = RubyVM::InstructionSequence.compile_file(___path)
# iseq could be cached here
iseq.eval_in_instance(___dsl_object)
```
Note that while instance_eval makes local variables available if the evaluated argument is a string, this new method would not (as the local variables can't be known at compile time). This discrepancy already exists between  RubyVM::InstructionSequence#eval and all other standard library functions named eval, so I assume it's okay.

This new method could also replace some use cases of Kernal#eval (any where the passing of local variables is not required).
# Implementation
From a cursory glance at the relevant code, this seems like a fairly simple feature to implement. Maybe an additional parameter to `#compile` is needed to change the ISEQ type, I'm not sure. If no one who is more experienced at working with Ruby internals wants to step up to implement this feature, I will try it myself.

# Discussion
There is a rejected feature #12093 about evaluating ISEQs with a binding (which is not possible since the compiler needs to know the local variables of a binding to compile for it, thus the request got rejected). There was some talk about evaling inside an instance in the comments, but I assume that was forgotten about due to the ticket being closed. Therefore I think opening this new ticket is justified.




-- 
https://bugs.ruby-lang.org/

Unsubscribe: <mailto:[e-mail]?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>