"&prock", not "&block"

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

2

On Nov 14, 8:28 pm, Greg W. [email protected] wrote:

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.

3

On Nov 14, 2007, at 17:28 , Greg W. 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.

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.

5

Eric H. 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.

6

On Nov 15, 2007, at 13:06 , Greg W. wrote:

Eric H. 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

7

On Nov 16, 2007, at 02:01 , Greg W. wrote:

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
^

8

Eric H. 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.