[ruby-core:25065] Re: Proposal: Simpler block format

Hi --

On Mon, 24 Aug 2009, Yehuda Katz wrote:

> I wrote:
>
>       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.

I disagree. The block-as-syntactic-element, plus the "yield"
semantics, are much easier to put across than describing the block as
a kind of weird method argument. I find the best thing is to detach
the argument list from the block in people's mind's completely, and
then everything makes sense: the different syntax, the fact that
Proc.new takes a block (which, if the block is already literally a
proc, makes for a kind of infinite regression), and the & semantics
which allow for proc/block interchange.

>             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?

I'm still not a fan of the bare {} to mean a Proc object. Maybe I'm
wrong, but I imagine having to peer much more closely at code to
figure it out than is currently the case, or at least have to check
for =>'s before I knew what I was looking at, which seems kind of
awkward.

I imagine I could adapt, but I'm still not seeing the big gain. Wasn't
the bigger problem the incompatibility of block and method calling
semantics, which has now gone away?


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