mark sparshatt wrote:I'd like advice on how to handle method invocations that include special block parameters such as
method() {do something}
The idea is to turn the block into a closure pmc. The problem is how to pass this to the method, so that it knows that it's a special block parameter. Particularly in a way so that a language which doesn't know about blocks can still call Ruby code.
Can't you just compile the code like this:
new_pad 0 newsub $clos, .Closure, _do_something method($clos) ... .sub _do_something new_pad -1 ...
and pass the closure as additional argument to the method?
This runs into issues of argument placement. The closure argument's not a real parameter any more than the object is a real parameter for a method call. It arguably ought to be separated out. The original design of the calling conventions had it as a separate parameter, but Larry convinced me to take it out. I'm thinking that, in retrospect, that was a sub-optimal decision.
On the other hand, I'm not sure an extra block slot's the right answer either, though it's more right than not. It'd have to go into the interpreter structure with the return continuation, calling object and method object, so that's another pointer that'd need to be copied, cleared, or set as appropriate. (though that's only a 1 cycle cost most places)
Still, I think it might be worth dedicating a slot to it. It's a handy feature, and if we open it up to perl & python I'd bet we'd see them using it.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
