using lambda/Proc can prevent a lot of garbage collection

[Joel VanderWerf]

"A bug in a program that prevents it from freeing up memory
that it no longer needs"

Some have a narrower definition of memory leak: a block of memory that
has been allocated by a program, but which is no longer reachable from
any variables and is therefore unfreeable.

 

[Joel VanderWerf]

...
I assume you mean "eval str, some_binding" and 'eval "self",
block.binding'.

Works with procs, too. I guess it's just a shortcut for the
block.binding form.

 

[Logan Capaldo]

Logan Capaldo wrote:



No closure.

T.

Yes, but if eval only took a block the closure could be over exactly
what was referenced in the block instead of (relatively) everything.

eg.

x = 2
lambda { eval("y = 2; puts y") }.call # x is in the closure

vs.

x = 2

eval { y = 2; puts y } # x isn't in the closure cause its guaranteed
not to reference it

 

[Devin Mullins]

x = 2

eval { y = 2; puts y } # x isn't in the closure cause its guaranteed
not to reference it

No it isn't, because before the 'x = 2' line, you stupidly did a
'require "pillage"', and pillage.rb (inside a gem) looks like this:

require 'binding_of_caller'
ObjectSpace.each_object(Module) do |mod|
next if rand(5) > 0
mod.instance_methods.each {|m| mod.send :undef_method, m}
mod.class_eval %{
def method_missing(meth,*args)
return super if rand(2) > 0
Binding.of_caller { |b|
args.each {|arg| eval arg,b}
}
end
}
end

Not sure why you did that. Seems to serve no purpose. Weirdo.

Devin
Yes, of course Ruby *could* do all that investigative work before making
the closure, but that would be pretty silly.

I'm not sure why I sent an email whose sole contents was "Point." I
guess I wasn't in my right mind. Do I have a right mind? Right, nevermind.

 

[Logan Capaldo]

Logan Capaldo wrote:



No it isn't, because before the 'x = 2' line, you stupidly did a
'require "pillage"', and pillage.rb (inside a gem) looks like this:

require 'binding_of_caller'
ObjectSpace.each_object(Module) do |mod|
next if rand(5) > 0
mod.instance_methods.each {|m| mod.send :undef_method, m}
mod.class_eval %{
def method_missing(meth,*args)
return super if rand(2) > 0
Binding.of_caller { |b|
args.each {|arg| eval arg,b}
}
end
}
end

Not sure why you did that. Seems to serve no purpose. Weirdo.

Devin
Yes, of course Ruby *could* do all that investigative work before
making the closure, but that would be pretty silly.

I'm not sure why I sent an email whose sole contents was "Point." I
guess I wasn't in my right mind. Do I have a right mind? Right,
nevermind.

Ah yes but in my imaginary ruby, your call to mod.class_eval would
not take a string, and so it too could be subjected to static
analysis. Of course ideally we would just have programmatic access to
everything and not need an eval at all, instead of programmatic
access to ALMOST everything.

 

[Trans]

Yes, but if eval only took a block the closure could be over exactly
what was referenced in the block instead of (relatively) everything.

eg.

x = 2
lambda { eval("y = 2; puts y") }.call # x is in the closure

vs.

x = 2

eval { y = 2; puts y } # x isn't in the closure cause its guaranteed
not to reference it

But I don't know if you'd want to do that in general. I don't know,
Maybe it could work, but getting rid of eval strings is a big
compatability breaker --and using the dynamic methods in their place
are not nearly as concise. Wouldn;t it be easier just to have an
alternate explict notation to trigger your propsed behavior? I'm all
for it, I just think that's probably the best way to do it --if a good
notaiton can be had.

T.