From: Joshua Ballanco <jballanc@...>
Date: 2011-10-03T16:32:05+09:00
Subject: [ruby-core:39857] Re: 2.0 feature questionnaire

--4e8964f1_17d78639_4992
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Monday, October 3, 2011 at 3:01 AM, =22Martin J. D=C3=BCrst=22 wrote:
> On 2011/10/02 9:51, Urabe Shyouhei wrote:
> =20
> > (10/01/2011 04:53 PM), Chuck Remes wrote:
> =20
> > > - Remove confusing proc/lambda/Proc differences
> > =20
> > proc is Proc and lambda is ->()=7B=7D. No confusion now.
> =20
> That's easy for people who know what a proc is, and what a lambda is. =20
> But that may not be everybody.
> =20
> A simplification in this area was on my wishlist, too. At the time, as =
=20
> far as I remember it, there were at least two axes on which these and =20
> simila constructs differed.
> =20
> One axis was the handling of parameters/attributes: strictly positional=
 =20
> or with all kinds of bells and whistles (splats, defaults,...), and =20
> whether a mismatch between actual and formal attributes triggered an =20
> error or not.
> =20
> Another axis was what happened in the case of a return: Jump out of the=
 =20
> construct only or also jump out of the surrounding method. There were =20
> also related differences for break and next.
> =20
> As far as I understand, there was quite a bit of work on the first axis=
. =20
> But if I look at the 1.8 and 1.9 Pickaxe books, the 1.8 book spends a =20
> bit less than 3 pages on Blocks, Closures, and Proc Objects, whereas th=
e =20
> 1.9 book spends 4 pages on the same topic.
> =20
> Anyway, if we get to a point where we can say:
> =20
> proc is Proc and does ..., and lambda is ->()=7B=7D and does ....
> (where the '...' parts are extremely simple), then and only then can we=
 =20
> say =22No confusion now.=22.

Here is a helpful way to think about it:

A lambda is an anonymous function. Like functions they have strict arity =
checking (you must pass the number of arguments specified) and they creat=
e their own return scope (i.e. return takes you out of the lambda/functio=
n).

A proc is a block of code. As with any vanilla do=E2=80=A6end constructio=
n in ruby, the number of arguments on the block does not need to match wi=
th what is passed to the block. Also, like do=E2=80=A6end, procs do not c=
reate their own return scope. You shouldn't return from a proc if you wou=
ldn't return from a do=E2=80=A6end in the same position (i.e. never).

Is that clearer=3F

- Josh
--4e8964f1_17d78639_4992
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline


                <div><span class=3D=22Apple-style-span=22 style=3D=22colo=
r: rgb(160, 160, 168); =22>On Monday, October 3, 2011 at 3:01 AM, =22Mart=
in J. D=C3=BCrst=22 wrote:</span></div>
                <blockquote type=3D=22cite=22 style=3D=22border-left-styl=
e:solid;border-width:1px;margin-left:0px;padding-left:10px;=22>
                    <span><div><div>On 2011/10/02 9:51, Urabe Shyouhei wr=
ote:<br><br><blockquote type=3D=22cite=22><div>(10/01/2011 04:53 PM), Chu=
ck Remes wrote:<br></div></blockquote><br><blockquote type=3D=22cite=22><=
div><blockquote type=3D=22cite=22><div>- Remove confusing proc/lambda/Pro=
c differences<br></div></blockquote><br>proc is Proc and lambda is -&gt;(=
)=7B=7D.  No confusion now.<br></div></blockquote><br>That's easy for peo=
ple who know what a proc is, and what a lambda is. <br>But that may not b=
e everybody.<br><br>A simplification in this area was on my wishlist, too=
. At the time, as <br>far as I remember it, there were at least two axes =
on which these and <br>simila constructs differed.<br><br>One axis was th=
e handling of parameters/attributes: strictly positional <br>or with all =
kinds of bells and whistles (splats, defaults,...), and <br>whether a mis=
match between actual and formal attributes triggered an <br>error or not.=
<br><br>Another axis was what happened in the case of a return: Jump out =
of the <br>construct only or also jump out of the surrounding method. The=
re were <br>also related differences for break and next.<br><br>As far as=
 I understand, there was quite a bit of work on the first axis. <br>But i=
f I look at the 1.8 and 1.9 Pickaxe books, the 1.8 book spends a <br>bit =
less than 3 pages on Blocks, Closures, and Proc Objects, whereas the <br>=
1.9 book spends 4 pages on the same topic.<br><br>Anyway, if we get to a =
point where we can say:<br><br>proc is Proc and does ..., and lambda is -=
&gt;()=7B=7D and does ....<br>(where the '...' parts are extremely simple=
), then and only then can we <br>say =22No confusion now.=22.<br></div></=
div></span></blockquote><div><br></div><div>Here is a helpful way to thin=
k about it:</div><div><br></div><div>A lambda is an anonymous function. L=
ike functions they have strict arity checking (you must pass the number o=
f arguments specified) and they create their own return scope (i.e. retur=
n takes you out of the lambda/function).</div><div><br></div><div>A proc =
is a block of code. As with any vanilla do=E2=80=A6end construction in ru=
by, the number of arguments on the block does not need to match with what=
 is passed to the block. Also, like do=E2=80=A6end, procs do not create t=
heir own return scope. You shouldn't return from a proc if you wouldn't r=
eturn from a do=E2=80=A6end in the same position (i.e. never).</div><div>=
<br></div><div>Is that clearer=3F</div><div><br></div><div>- Josh</div>
            
--4e8964f1_17d78639_4992--