Yes, it's interesting to be reminded of all this again.
Much as I love Ruby, I hate having multiple versions of essentially the same
concept which differ in subtle ways. I would find it more aesthetically
pleasing if a tiny Ruby core could bootstrap the whole language - and it
might make it easier to port (and understand).
Now, I wonder why you couldn't approach this problem from the other
direction: instead of having two or more different types of lambda, which
handle 'return' semantics differently, have a single type of lambda and two
different return statements. For example:
return val # return from enclosing method
result val # return from this block only
Internally, you could implement 'return' semantics using catch and throw:
def foo
... some code
end
# could be implemented as something like this:
define_method(:foo) do
catch(:return) do
... some code
end
end
module Kernel
def return(rc=nil)
throw(:return, rc)
end
end
The other difference concerns arity. I don't see why argument checking can't
be done everywhere, as long as you have the option of explicitly allowing
variable arguments where you want them:
p1 = Proc.new { |x=nil,y=nil| ... } # accept 2 or fewer args
p2 = Proc.new { |x, y, *z| ... } # accept 2 or more args
p3 = Proc.new { |*x| ... } # no more single-arg special case!
That is, use the same argument list handling for a 'def' method definition,
a block, and a Proc/proc/lambda.
Anyway, that's just a couple of random thoughts. No doubt it's only when you
implement such a cut-down language that you'd find out what the pitfalls are
in practice 
Regards,
Brian.
···
On Tue, Feb 06, 2007 at 04:00:44AM +0900, Pit Capitain wrote:
gwtmp01@mac.com schrieb:
>(... useful infos about procs ...)
Very interesting! Thanks for sharing your experiments.
