f



"&prock", not "&block"

In all of the code below, "prock" by itself is always a proc, while the
combination "&prock" is always a block:

    def my_proc &prock    # accepts a block
      prock               # returns a proc
    end

    prock = my_proc { p "Hello, world" }

    prock.call

    def doit &prock  # param is redundant, but illustrative
      yield             # yields to &prock, a block
    end

    doit &prock         # same as 'doit { p "Hello, world" }'

So, it seems to me that "prock" above is distinctly clearer than
"block".  ("proc" would be better still, but it's taken.)

My only problem with "prock" is that my eye tends to scan it as p-rock
instead of the desired proc-k.  But it still seems better than "block".
Any other ideas?  "proce" perhaps?  "procc"?
-- 
Posted via http://www.ruby-forum.com/.

0
greg.weeks (24)
11/15/2007 1:28:16 AM
comp.lang.ruby 48886 articles. 0 followers. Post Follow

7 Replies
883 Views

Similar Articles

[PageSpeed] 30


On Nov 14, 8:28 pm, Greg Weeks <greg.we...@arm.com> wrote:
> In all of the code below, "prock" by itself is always a proc, while the
> combination "&prock" is always a block:
>
>     def my_proc &prock    # accepts a block
>       prock               # returns a proc
>     end
>
>     prock = my_proc { p "Hello, world" }
>
>     prock.call
>
>     def doit &prock  # param is redundant, but illustrative
>       yield             # yields to &prock, a block
>     end
>
>     doit &prock         # same as 'doit { p "Hello, world" }'
>
> So, it seems to me that "prock" above is distinctly clearer than
> "block".  ("proc" would be better still, but it's taken.)
>
> My only problem with "prock" is that my eye tends to scan it as p-rock
> instead of the desired proc-k.  But it still seems better than "block".
> Any other ideas?  "proce" perhaps?  "procc"?

use something more semantically relevant when you can:

  &action
  &event
  &what_i_do_on_wednesdays

T.

0
transfire (2969)
11/15/2007 2:48:05 AM
On Nov 14, 2007, at 17:28 , Greg Weeks wrote:
> In all of the code below, "prock" by itself is always a proc, while  
> the
> combination "&prock" is always a block:

Class doesn't matter, methods do.  I'm (almost) always passing in a  
block, so its a block.

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars



0
drbrain (2203)
11/15/2007 10:39:36 AM
Trans wrote:
> use something more semantically relevant when you can:
> 
>   &action
>   &event
>   &what_i_do_on_wednesdays

Certainly, in real-life code.

I was thinking of examples in textbooks where the reader is trying to
sort out the difference between blocks and procs.  In these examples,
I've seen the variable "block" used -- eg, in "Block, Closures, and Proc
Objects" in "The Ruby Language" in Pickaxe -- and I find it unappealing
to remind myself that "block" is a proc, and "&block" is a block.
-- 
Posted via http://www.ruby-forum.com/.

0
greg.weeks (24)
11/15/2007 8:34:12 PM
Eric Hodel wrote:
> Class doesn't matter, methods do.

You're preaching to the choir :-)

> I'm (almost) always passing in a block, so its a block.

If you're passing in a block, then the method parameter is something
like "&foo".  If you're passing in a proc, then the message parameter is
something like "foo".  In either case, in the method body, "&foo" is a
block, and "foo" is a proc.

It may be that "&foo" is pedagogically described as the "foo" parameter
with an "&" modifier.  But that is misleading.  The block argument is
bound to "&foo", not to "foo".  And the block argument is accessible in
the method body -- as "&foo".

So in all cases, "&foo" is a block iff "foo" is a proc.
-- 
Posted via http://www.ruby-forum.com/.

0
greg.weeks (24)
11/15/2007 9:06:54 PM
On Nov 15, 2007, at 13:06 , Greg Weeks wrote:
> Eric Hodel wrote:
>> Class doesn't matter, methods do.
>
> You're preaching to the choir :-)
>
>> I'm (almost) always passing in a block, so its a block.
>
> If you're passing in a block, then the method parameter is something
> like "&foo".

You can't make a variable &foo.

   def x(&foo); end

Says that if you pass in a block, assign it to the foo variable.

   mything = ...
   x(&mything)

Says call mything.to_proc and pass that result as a block to #x.

If you see & used outside of those two contexts, it is the & method.

> If you're passing in a proc, then the message parameter is  
> something like "foo".  In either case, in the method body, "&foo"  
> is a block, and "foo" is a proc.

Class and type don't matter, methods do.

If I call x(&5), Ruby will call 5.to_proc for me and pass the result  
of that along.  If I try to use &foo as a variable, ruby gives a  
syntax error.

You can only use &foo for describing a method argument, or for  
passing an argument to a method.

> It may be that "&foo" is pedagogically described as the "foo"  
> parameter
> with an "&" modifier.  But that is misleading.

This is correct, and this is what happens.  Its not misleading.

&foo works the same as *foo.

If I put *foo in the method signature, all the arguments will be  
collected into foo as an Array, like &foo collects a block into foo  
as a Proc.

If I call a method and use *foo as one of the parameters, Ruby will  
call foo.to_ary and pass the results to the method like &foo calls  
foo.to_proc.

Both *foo and &foo are optional.  You won't get an ArgumentError if  
you omit an item with *foo or a block with &foo.

If * is the "splat" operator, & is the "block splat" ("blockify"?)  
operator.

> The block argument is bound to "&foo", not to "foo".  And the block  
> argument is accessible in the method body -- as "&foo".

No, it is bound too foo, not &foo.  &foo is not a variable name.

> So in all cases, "&foo" is a block iff "foo" is a proc.

def z(&foo)
   p foo
end

z() # => nil

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

0
drbrain (2203)
11/16/2007 9:19:45 AM
Eric Hodel wrote:
> > It may be that "&foo" is pedagogically described as the "foo"  
> > parameter with an "&" modifier.  But that is misleading.
> 
> This is correct, and this is what happens.  Its not misleading.

I take your point.  Thanks for the correction.

Nevertheless, even though the argument is a block, the parameter foo is
not.  If you want to use the *block* argument in the method body, you
use the expression &foo, not foo.  foo is a proc; &foo -- an expression,
not a parameter as I erroneously said -- is a block.

> def z(&foo)
>    p foo
> end
> 
> z() # => nil

Because no block was supplied.
-- 
Posted via http://www.ruby-forum.com/.

0
greg.weeks (24)
11/16/2007 10:01:39 AM
On Nov 16, 2007, at 02:01 , Greg Weeks wrote:
> Eric Hodel wrote:
>>> It may be that "&foo" is pedagogically described as the "foo"
>>> parameter with an "&" modifier.  But that is misleading.
>>
>> This is correct, and this is what happens.  Its not misleading.
>
> I take your point.  Thanks for the correction.
>
> Nevertheless, even though the argument is a block, the parameter  
> foo is
> not.  If you want to use the *block* argument in the method body, you
> use the expression &foo, not foo.

If by 'use the block argument in the method body' you mean 'call  
methods on the block argument', you must use 'foo', as  
'&foo.some_method' is a syntax error.  If by 'use [...]' you mean  
'pass foo as a block argument to another method' (like the array- 
splat * syntax) you are correct.

> foo is a proc; &foo -- an expression, not a parameter as I  
> erroneously said -- is a block.

&foo is not an expression, & can only be used to modify argument  
passing:

$ ruby
def x(&foo) &foo end
-:1: parse error
def x(&foo) &foo end
              ^
def x(&foo) (&foo) end
-:2: parse error
def x(&foo) (&foo) end
               ^

--
Poor workers blame their tools. Good workers build better tools. The
best workers get their tools to do the work for them. -- Syndicate Wars

0
drbrain (2203)
11/17/2007 3:19:20 AM
Reply: