From: Yehuda Katz Date: 2009-08-24T08:24:53+09:00 Subject: [ruby-core:25061] Re: Proposal: Simpler block format --00c09f905f9174e8c10471d768ad Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I was actually just discussing that with Ujihisa. Unfortunately, it would break far too much code to be practical (think, every single Ruby script out there). -- Yehuda On Sun, Aug 23, 2009 at 4:17 PM, wrote: > > On Sun, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto > > wrote: > > > >> Hi, > >> > >> In message "Re: [ruby-core:25049] Re: Proposal: Simpler block format" > >> on Sun, 23 Aug 2009 15:53:03 +0900, Yehuda Katz > >> writes: > >> > >> |Things that currently don't parse are fine to become blocks. I'd be > >> worried > >> |about a case that currently parsed fine as a Hash but might be expected > >> to > >> |be parsed as a block if this feature existed. Can you think of any? > >> > >> I don't worry about the ambiguity for the parser, but have anxiety for > >> humans. Under the new syntax, when we see > >> > >> m {"this is a block not a proc"} > >> > >> there are two possibility. And it would be burden for mind of the > >> programmers. That's the reason I insisted the past proposal (that > >> was from David Black, IIRC). This time, we have working code for the > >> proposal, so we can try. Let's see how we feel. > > > > > > The compelling this for me is that it makes methods that take multiple > > blocks easier for programmer to read. For programmer, one big confusion > in > > Ruby is difference between proc, block, lambda and method. Unifying > syntax > > for block and proc shows that they are really just same thing, with proc > > passed as parameter and block passed as special parameter. > > > > Then whenever programmer sees { something } they know it is "proc" with > > lexical scope, and whenever programmer sees ->{ something } they know it > > is > > "lambda" with function scope. > > > > I would even be in favor of def { } as lambda syntax, which would make > > clear > > to programmer that this block behaves just like normal method. Then we > > have > > just two things: def for method-scope (def something() end and def { }) > > and > > bare { } for block scope. > > if we're throwing ideas out there, i've always thought it would be a good > idea to do exactly what you've proposed, plus take { } away from hashes > and use [ ] instead. that way { } is just for proc, method, etc., and [ ] > is for arrays and hashes. what's inside of the [ ] determines whether it's > an array or hash. thus: > > [1, 2, 4, 9] # array > [1 => 2, 4 => 9] # hash > [a: 'b', c: 'd'] # hash > [a: 'b', 1, 2] # error or hash > { ... } # proc, always > def { ... } # method, lambda > ->{ ... } # method, lambda > > this breaks everything though. but we _are_ still in 1.9, and one can > dream... > > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --00c09f905f9174e8c10471d768ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I was actually just discussing that with Ujihisa. Unfortunately, it would b= reak far too much code to be practical (think, every single Ruby script out= there).

-- Yehuda

On = Sun, Aug 23, 2009 at 4:17 PM, <danielcavanagh@aanet.com.au> wrote:<= br>
> On S= un, Aug 23, 2009 at 3:33 PM, Yukihiro Matsumoto
> <matz@ruby-lang.org>wr= ote:
>
>> Hi,
>>
>> In message "Re: [ruby-core:25049] Re: Proposal: Simpler block= format"
>> =A0 =A0 on Sun, 23 Aug 2009 15:53:03 +0900, Yehuda Katz <wycats@gmail.com>
>> writes:
>>
>> |Things that currently don't parse are fine to become blocks. = I'd be
>> worried
>> |about a case that currently parsed fine as a Hash but might be ex= pected
>> to
>> |be parsed as a block if this feature existed. Can you think of an= y?
>>
>> I don't worry about the ambiguity for the parser, but have anx= iety for
>> humans. =A0Under the new syntax, when we see
>>
>> =A0m {"this is a block not a proc"}
>>
>> there are two possibility. =A0And it would be burden for mind of t= he
>> programmers. =A0That's the reason I insisted the past proposal= (that
>> was from David Black, IIRC). =A0This time, we have working code fo= r the
>> proposal, so we can try. =A0Let's see how we feel.
>
>
> The compelling this for me is that it makes methods that take multiple=
> blocks easier for programmer to read. For programmer, one big confusio= n in
> Ruby is difference between proc, block, lambda and method. Unifying sy= ntax
> for block and proc shows that they are really just same thing, with pr= oc
> passed as parameter and block passed as special parameter.
>
> Then whenever programmer sees { something } they know it is "proc= " with
> lexical scope, and whenever programmer sees ->{ something } they kn= ow it
> is
> "lambda" with function scope.
>
> I would even be in favor of def { } as lambda syntax, which would make=
> clear
> to programmer that this block behaves just like normal method. Then we=
> have
> just two things: def for method-scope (def something() end and def { }= )
> and
> bare { } for block scope.

if we're throwing ideas out there, i've always thought = it would be a good
idea to do exactly what you've proposed, plus take { } away from hashes=
and use [ ] instead. that way { } is just for proc, method, etc., and [ ] is for arrays and hashes. what's inside of the [ ] determines whether i= t's
an array or hash. thus:

[1, 2, 4, 9] =A0 =A0 # array
[1 =3D> 2, 4 =3D> 9] # hash
[a: 'b', c: 'd'] # hash
[a: 'b', 1, 2] =A0 # error or hash
{ ... } =A0 =A0 =A0 =A0 =A0# proc, always
def { ... } =A0 =A0 =A0# method, lambda
->{ ... } =A0 =A0 =A0 =A0# method, lambda

this breaks everything though. but we _are_ still in 1.9, and one can
dream...





--
Yehuda Katz
Develope= r | Engine Yard
(ph) 718.877.1325
--00c09f905f9174e8c10471d768ad--