From: Brian Candler <B.Candler@...>
Date: 2007-02-06T06:28:48+09:00
Subject: Re: Proc vs lambda vs proc

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.

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.