Yukihiro Matsumoto wrote:
> Hi,
> 
> In message "Re: Anonymous methods, blocks etc. (Cont. 'default block params')"
>     on Tue, 1 Nov 2005 03:52:13 +0900, Zach Dennis <zdennis / mktec.com> writes:
> 
> |Is the -> syntax still open for debate Matz? I agree with Austin on 
> |this. The syntax here is just ugly.
> 
> It's always open.  But define "ugly" first.
> 
> 							matz.

Here are some of my thoughts on the syntax "->(a=5,b=1){ }" to denote it as ugly.
  * -> is not a common construct in any language that I know of to represent anonymous function 
declaration, while lambda is. Instead -> is a recognized operator for dereferencing
  * -> can be hard for readability given code like:
      m=->(a,b){a**b}
     OR
      m=->(a,b){ arr = [];a.times { |i| arr << i**b } }

    in my opinion it is easier to visually separate such constructs utilizing identifiable word 
construct like lambda:
       m=lambda(a,b){ a**b }
     OR
       m=lambda(a,b) {
         arr = []
         a.times { |i| arr << i**b }
       }

  * utilizing other operators such as assignment or comparison (although I don't know where someone 
would use comparison operators here) cause visual confusion, and makes it easier for programmer to 
overlook the correct interpretation of the code:
     m=->(a,b){ .. }    sort of looks like   m=>a(b){ ...block here.. }
   whereas
     m=lambda(a,b){ ... }    is hard to confuse with any other operators

  * Aesthetically, in my opinion -> as an operator is not as elegant as other ruby constructs such 
as things like:
       lambda { }
       proc { }
       do ... end
       :symbol

    The one area where there is another such constructor is with regular expressions, /.../, but 
that seems to be universally used construct for regular expressions.

Now if you do not agree with my opinions and you choose to keep -> would it be possible to have:
   ->(a,b){ .. }
  and
   lambda(a,b){ }

have the same behavior?

On another note of the questions raised by your blog and translated by _why the following questions 
are statement is set forth:

"He wants a good idea which fulfill below condition:
     * It?s able to express anonymous function.
     * It puts in front of parameters.
     * It?s good mix of sign which have not been used until now.
     * Many people feel comfortable (if possible)."

Would the following example fulfill the first two capabilities and potentially the fourth?
   proc = lambda (a, b=5){ a**b }

If you do not want to change behavior of lambda, I have another question. proc_lambda just calls 
proc_alloc. It looks like proc_lambda is either being used as a placeholder for a better 
implementation (anonymous function?) or it was just an easy way to implement lambda and make people 
happy a few years ago.?

Also, according to your examples of using "->" with blocks. Example:
   for list -> x { ... }
   hash.each -> (k,v="none") { ... }

I do not think the "->" can be used in:
   proc = -> (x, y) { ... }

and keep the same consistency and clarity. Also would the following replace existing block syntax?
   hash.each -> (k,v="none") { ... }

Or would the above code and the existing block syntax both remain?

In your blog Matz you mention that you are considering -> operator because of Perl6. Ruby has a 
strong user base now and it is growing. People like many of the similarities that Ruby has with 
Perl, but many of those same people are very happy that you did not pull over things from Perl like 
hash or array dereferencing. I think the -> operator is one of these  spots where it should be left 
in Perl. Let perl people use ugly symbol based operators so it can add confusion, let ruby people 
use something better. Also I do not claim to know what the better is. Perhaps it is lambda, perhaps 
it is something else....

Thank you for your time Matz to review this.

Zach

As references I reviewed the following sources:
- http://redhanded.hobix.com/inspect/blockAndLambda.html
- http://www.rubyist.net/~matz/?date=20050722 (babelfish translation, similar to redhanded blog above)
- http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/161133 (the whole thread)
-