A block is an everted (inside-out) method.

A normal function:

  def foo(x)
    x + 42
  end

A similar block:

  y = 42
  block_user do |x|
    x + y
  end

The call site for ''foo'' would just look like ''foo(12)''. The name of ''foo'' is on 
the outside, its calling parens are on the outside, and its behavior is 
on the inside.

The block turns this pattern inside out. The call site (''yield(12)'' or 
''block.call(12)'') is inside the ''block_user''.

The behavior is on the outside.

So when ''foo'' takes its argument, it needs delimiters to name the argument 
for the interpreter. ''(x)''.

When ''block_user'' passes ''x'', the block needs delimiters to name its 
argument, so its block body can use it. ''|x|''.

And because the behavior is on the outside, it can share variables from 
its enclosing scope. ''foo()'', by contrast, can only share variables from 
its enclosing class.

-- PhlIp

''"Inside Out Methods"?  You certainly have a unique perspective on blocks.  As I understand it, blocks are simply a name for an (often limited) form of HigherOrderFunctions.  Depending on the language, they can be lexically or dynamically scoped, and lexical scoping allows formation of ''closures'' (which are what make blocks really useful).  The above block would be equivalent to:''
   let y = 42 in \x -> (x + y)
      (or, for a variable 'y')
   let y = new cell<int>(42) in \x -> (x + dereference(y))  
''Some languages languages make 'dereference(y)' implicit, of course.  And you'd want to let someone else see 'y' before embedding it in the function if the mutability of y is to be of any use to you.''

''Anyhow, saying that 'foo(12)' necessarily has its behavior 'on the inside' seems a bit questionable even for 'lower order' methods, given access to global variables:''
  extern int y;
  int foo(int x) { return (x + y); }

''As such, you may want to rethink your reasoning for your terminology a bit.''

Won't happen. Not enough people know the word "everted" for it to work. (-: