"&prock", not "&block"

ruby-talk
1

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/.

2

use something more semantically relevant when you can:

  &action
  &event
  &what_i_do_on_wednesdays

T.

···

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

3

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

···

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:

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

4

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/\.

5

Eric Hodel wrote:

Class doesn't matter, methods do.

You're preaching to the choir :slight_smile:

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/\.

6

Eric Hodel wrote:

Class doesn't matter, methods do.

You're preaching to the choir :slight_smile:

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

···

On Nov 15, 2007, at 13:06 , Greg Weeks wrote:

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

7

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/\.

8

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
               ^

···

On Nov 16, 2007, at 02:01 , Greg Weeks wrote:

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