--00c09f89928f2295df0471d843e2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sun, Aug 23, 2009 at 4:53 PM, David A. Black <dblack / rubypal.com> wrote: > Hi -- > > On Mon, 24 Aug 2009, Yehuda Katz wrote: > >> >> 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. >> > > I have to admit that this strikes me as a solution in search of a > problem, in that I've never had any trouble reading methods that take > Proc objects as arguments. Also, I think that with the unification of > block and method parameter semantics, things are getting a lot less > confusing as to the differences among them. I can just speak for myself: the fact that there were multiple different "code block" syntaxes, each with their own semantics, has been a source of historical pain for me. > I don't consider a block to be the same thing as a proc, nor do I > consider it a method argument. The block is part of the method-call > syntax; in itself, it isn't an object (just as the argument list is > not, in itself, an object). There's no conceptual reason for programmers to differentiate between Proc objects and the block passed to methods, except that the latter provides some extra syntax to make the common use-case pretty. Trying to explain the difference to new Rubyists strikes me as something we'd be better off never having to do. > 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. >> > > One danger of { something } being a proc is that it does away with the > error message for odd-numbered hashes -- an edge case, admittedly, but > still. I don't think I've ever encountered this error except for Hash[*something], which would not be affected by this change. > 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. >> > > Dave Thomas brought up the def { } thing at RubyConf 2005, I believe, > and got a big round of applause :-) It's definitely way better than > ->() (which I still sort of hope will disappear, though my hope is > fading). Then we agree :) Don't you think that having just two "keywords" for code blocks (def/bare {}) would simplify things conceptually? > > > > David > > -- > David A. Black / Ruby Power and Light, LLC / http://www.rubypal.com > Q: What's the best way to get a really solid knowledge of Ruby? > A: Come to our Ruby training in Edison, New Jersey, September 14-17! > Instructors: David A. Black and Erik Kastner > More info and registration: http://rubyurl.com/vmzN > > -- Yehuda Katz Developer | Engine Yard (ph) 718.877.1325 --00c09f89928f2295df0471d843e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br><br><div class="gmail_quote">On Sun, Aug 23, 2009 at 4:53 PM, David A. Black <span dir="ltr"><dblack / rubypal.com></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> Hi --<div class="im"><br> <br> On Mon, 24 Aug 2009, Yehuda Katz wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> The compelling this for me is that it makes methods that take multiple<br> blocks easier for programmer to read. For programmer, one big confusion in<br> Ruby is difference between proc, block, lambda and method. Unifying syntax<br> for block and proc shows that they are really just same thing, with proc<br> passed as parameter and block passed as special parameter.<br> </blockquote> <br></div> I have to admit that this strikes me as a solution in search of a<br> problem, in that I've never had any trouble reading methods that take<br> Proc objects as arguments. Also, I think that with the unification of<br> block and method parameter semantics, things are getting a lot less<br> confusing as to the differences among them.</blockquote><div><br></div><div>I can just speak for myself: the fact that there were multiple different "code block" syntaxes, each with their own semantics, has been a source of historical pain for me.</div> <div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">I don't consider a block to be the same thing as a proc, nor do I<br> consider it a method argument. The block is part of the method-call<br> syntax; in itself, it isn't an object (just as the argument list is<br> not, in itself, an object).</blockquote><div><br></div><div>There's no conceptual reason for programmers to differentiate between Proc objects andhe block passed to methods, except that the latter provides some extra syntax to make the common use-case pretty. Trying to explain the difference to new Rubyists strikes me as something we'd be better off never having to do.</div> <div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Then whenever programmer sees { something } they know it is "proc" with<br> lexical scope, and whenever programmer sees ->{ something } they know its<br> "lambda" with function scope.<br> </blockquote> <br></div> One danger of { something } being a proc is that it does away with the<br> error message for odd-numbered hashes -- an edge case, admittedly, but<br> still.</blockquote><div><br></div><div>I don't think I've ever encountered this error except for Hash[*something], which would not be affectedy this change.</div><div>/div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> <div class="im"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> I would even be in favor of def { } as lambda syntax, which would make clear<br> to programmer that this block behaves just like normal method. Then we have<br> just two things: def for method-scope (def something() end and def { }) and<br> bare { } for block scope.<br> </blockquote> <br></div> Dave Thomas brought up the def { } thing at RubyConf 2005, I believe,<br> and got a big round of applause :-) It's definitely way better than<br> ->() (which I still sort of hope will disappear, though my hope is<br> fading).</blockquote><div><br></div><div>Then we agree :)</div><div><br></div><div>Don't you think that having just two "keywords" for code blocks (def/bare {}) would simplify things conceptually?</div><div> /div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><br> <br> <br> David<br> <br> -- <br> David A. Black / Ruby Power and Light, LLC / <a href="http://www.rubypal.com" target="_blank">http://www.rubypal.com</a><br> Q: What's the best way to get a really solid knowledge of Ruby?<br> A: Come to our Ruby training in Edison, New Jersey, September 14-17!<br> Instructors: David A. Black and Erik Kastner<br> More info and registration: <a href="http://rubyurl.com/vmzN" target="_blank">http://rubyurl.com/vmzN</a><br> <br> </div></div></blockquote></div><br><br clear="all"><br>-- <br>Yehuda Katz<br>Developer | Engine Yard<br>(ph) 718.877.1325<br> --00c09f89928f2295df0471d843e2--