From: Yehuda Katz Date: 2009-08-24T14:48:26+09:00 Subject: [ruby-core:25078] Re: Proposal: Simpler block format --00c09f88cfc32151bc0471dcc433 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 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 >> 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. >> >> >> > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --00c09f88cfc32151bc0471dcc433 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Essentially, we currently have two semantic constructs: method-style and bl= ock-style. I am suggesting that we take the literals of each style and use = them as literals whenever those semantics are expected.

=A0=A0 =A0my_method { block_semantics }

In th= is 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.

=A0=A0 =A0my_method({ still_block_semantics })

Similarly:

=A0=A0 =A0def method_n= ame() method_semantics end

In this case, def is th= e literal for method-semantics. I am suggesting that we extend the use of t= his literal to the other case where method-semantics are used: Lambdas.

=A0=A0 =A0name =3D def { still_method_semantics }
=

As you can see, by using the same literals for equivale= nt 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 yie= ld will yield to the block. When he sees bare {} he knows that block semant= ics 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 all= owed for default arguments. Since that has since been fixed for || args, wh= at 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 use= d to. In addition, it removes the case that I find incredibly hard to read:=

-> a, b { a + b }

For defaults, from:

-> a =3D 1 { a + 3 }

to:

->{ |a=3D1| 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 -> implem= entation and the bare {} implementation. It unifies the idea of a separate = identifier with syntax that all ruby programmers are accustom to today.

=A0- Evan



On Aug 23, 2009, at 9:21 PM, Yukihiro Matsumoto wrote:

Hi,

In message "Re: [ruby-core:25068] Re: Proposal: Simpler block format&q= uot;
=A0 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. =A0I assume your def {} proposal
is to declare an anonymous procedure object, which is NOT a method at
all. =A0For me, the difference is big enough to reject the proposal.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0matz.







--
Yehuda Katz=
Developer | Engine Yard
(ph) 718.877.1325
--00c09f88cfc32151bc0471dcc433--