Abstracting from the syntax details, I think some streamlining like the 
one below would be highly beneficial to Ruby.

It's very difficult to understand why in Ruby, with its great 
streamlined design (e.g. "everything is an object", "everything is an 
expression"), when it comes to "chunks of code with parameters", there 
is such a mess. In something like Perl, the current 
proc/block/lambda/method stuff might be called "great design". By Ruby 
stanards, it's definitely not.

[in an earlier mail, Matz wrote:]
 > The def keyword is to define a method.  I assume your def {} proposal
 > is to declare an anonymous procedure object, which is NOT a method at
 > all.  For me, the difference is big enough to reject the proposal.

What about the def keyword for methods on the main object? These, by 
virtue of the 'main object trick', are technically methods (i.e. chunks 
of code with a self). But the way they are used, in at least 99% of the 
cases, and the way many people (including myself) think about them is as 
procedure objects (i.e. chunks of code without a self). So we already 
have a case where the above difference pretty much exists but the syntax 
is the same. What essentially remains is the difference between "has a 
name" and "anonymous", which is easy to handle in an uniform way for 
both humans and computers.


Regards,    Martin.

On 2009/08/24 14:48, Yehuda Katz wrote:
> Essentially, we currently have two semantic constructs: method-style and
> block-style. I am suggesting that we take the literals of each style and use
> them as literals whenever those semantics are expected.
>      my_method { block_semantics }
>
> In this case, { block } is the literal for block-semantics. I am suggesting
> that we extend the use of this literal to the other case where
> block-semantics are used: Procs.
>
>      my_method({ still_block_semantics })
>
> Similarly:
>
>      def method_name() method_semantics end
>
> In this case, def is the literal for method-semantics. I am suggesting that
> we extend the use of this literal to the other case where method-semantics
> are used: Lambdas.
>
>      name = def { still_method_semantics }
>
> As you can see, by using the same literals for equivalent constructs, we
> simplify the problem in the mind of the programmer. When he sees "def" he
> knows that method semantics are to be used, and required arguments are
> required, return will return from the block, and yield will yield to the
> block. When he sees bare {} he knows that block semantics are used, all
> arguments are optional, return will return from enclosing "def", and yield
> will yield to block passed into enclosing "def".
>
> This will always be true, no matter if lambda is being used, proc is being
> used, method is being used, or block is being used.
>
> -- Yehuda
>
> On Sun, Aug 23, 2009 at 9:36 PM, Evan Phoenix<evan / fallingsnow.net>  wrote:
>
>> Hi everyone,
>>
>> I know that one of the original reasons for having ->  was because it
>> allowed for default arguments. Since that has since been fixed for || args,
>> what about simply moving where the arguments for ->  are?
>>
>> Rather than:
>>
>> ->(a,b) { a + b }
>>
>> you have:
>>
>> ->{ |a,b| a + b }
>>
>> I find that quite a bit easier to read, and it's syntax everyone is used
>> to. In addition, it removes the case that I find incredibly hard to read:
>>
>> ->  a, b { a + b }
>>
>> For defaults, from:
>>
>> ->  a = 1 { a + 3 }
>>
>> to:
>>
>> ->{ |a=1| a + 3 }
>>
>> Seems like it would be fine to allow space between ->  and { as it is now as
>> well:
>>
>> ->  { |a,b| a + b }
>>
>> I think of this as sort of a middle ground between the current ->
>> implementation and the bare {} implementation. It unifies the idea of a
>> separate identifier with syntax that all ruby programmers are accustom to
>> today.
>>
>>   - Evan
>>
>>
>>
>> On Aug 23, 2009, at 9:21 PM, Yukihiro Matsumoto wrote:
>>
>>   Hi,
>>> In message "Re: [ruby-core:25068] Re: Proposal: Simpler block format"
>>>    on Mon, 24 Aug 2009 13:03:53 +0900, brian ford<brixen / gmail.com>
>>> writes:
>>>
>>> |Could we add def {} and see by usage which prevails? Or take a
>>> |world-wide vote (perhaps weighted by number of lines of Ruby code
>>> |written by the voter)?
>>>
>>> The def keyword is to define a method.  I assume your def {} proposal
>>> is to declare an anonymous procedure object, which is NOT a method at
>>> all.  For me, the difference is big enough to reject the proposal.
>>>
>>>                                                         matz.
>>>
>>>
>>>
>>
>
>

-- 
#-# Martin J. D?rst, Professor, Aoyama Gakuin University
#-# http://www.sw.it.aoyama.ac.jp   mailto:duerst / it.aoyama.ac.jp