[#76442] [Ruby trunk Feature#11741] Migrate Ruby to Git from Subversion — naruse@...
Issue #11741 has been updated by Yui NARUSE.
3 messages
2016/07/19
[#76515] [Ruby trunk Bug#12610] webrick: protect from httpoxy — nagachika00@...
Issue #12610 has been updated by Tomoyuki Chikanaga.
3 messages
2016/07/22
[ruby-core:76316] [Ruby trunk Feature#12086] using: option for instance_eval etc.
From:
shugo@...
Date:
2016-07-08 07:56:20 UTC
List:
ruby-core #76316
Issue #12086 has been updated by Shugo Maeda.
Nobuyoshi Nakada wrote:
> I'm against `instance_eval` under the hood by libraries.
I used to be against it too, but it's common now whether `using:` is available or not.
Let me talk about a use case.
I wrote a packrat parser library called radd_djur (https://github.com/shugo/radd_djur) before.
radd_djur uses refinements to implement an internal DSL to define grammar rules.
```ruby
require "radd_djur"
using RaddDjur::DSL
calc = RaddDjur::Grammar.new(:expr) {
define :expr do
[:int, "+", :int].bind { |x, *, y|
ret x + y
} /
[:int, "-", :int].bind { |x, *, y|
ret x - y
}
end
define :int do
(?0..?9).one_or_more.bind { |xs|
ret xs.foldl1(&:+).to_i
}
end
}
p calc.parse("123+456")
```
`define` and `ret` are provided by `instance_eval`, and `bind`, `/`, and `one_or_more`
are provided by refinements.
It looks cool, but there are two problems here:
1. We have to write `using RaddDjur::DSL` explicitly.
2. Refinements for DSL is available out of the grammar rules.
If `instance_eval(using: refinement)` is introduced, RaddDjur::DSL can be activated
only in the block given to `RaddDjur::Grammar.new`, and these two problems will be solved.
Note that `instance_eval` and refinement activation have to be done atomically in this case.
That's why I proposed this feature as a new option of `instance_eval`.
----------------------------------------
Feature #12086: using: option for instance_eval etc.
https://bugs.ruby-lang.org/issues/12086#change-59552
* Author: Shugo Maeda
* Status: Open
* Priority: Normal
* Assignee:
----------------------------------------
Currently refinements can be activated only in toplevel or class/module definitions.
If they can be activated in block-level, it's useful to implement internal DSLs.
How about to add a new option using: for Kernel#instance_eval and Moule#{class,module}_eval?
```ruby
module FixnumDivExt
refine Fixnum do
def /(other)
quo(other)
end
end
end
p 1 / 2 #=> 0
instance_eval(using: FixnumDivExt) do
p 1 / 2 #=> (1/2)
end
p 1 / 2 #=> 0
```
Proof-of-concept implementation is available at <https://github.com/shugo/ruby/tree/eval_using>.
In my previous proposal before Ruby 2.0, refinements used in a class or module are
implicitly activated by instance_eval and class_eval, but now I think it's better to
explicitly specify refinements to be activated.
Considerations:
* In the PoC implementation, refined methods are not cached inline, and thus it decreases
the performance of refined method call.
If there is a way to guarantee that blocks never be evaluated in different environments,
refined methods can be cached inline.
* {instance,class,module}_exec cannot be extended in the same way, because they take arbitrary
arguments and there's no way to distinguish an option hash from the last argument hash.
--
https://bugs.ruby-lang.org/
Unsubscribe: <mailto:ruby-core-request@ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>