[ruby-core:41683] Re: Documentation of the language itself (syntax, meanings, etc)

On Dec 15, 2011, at 11:58 AM, Rodrigo Rosenfeld Rosas wrote:

> For instance, I wanted to know if this is possible:
>=20
> class MyViewRenderer < DefaultRender # DefaultRender defines the =
'render' method
>  def list
>    render_and_return[view: 'not_allowed'] unless allowed?
>    render view: 'list' # shouldn't get called
>  end
>=20
>  protected
>=20
>  def render_and_return
>    proc {|*args| render *args; return }
>  end
>=20
>  def allowed?
>    false
>  end
> end
>=20
> Yeah, I know several folks will point me out that I should be using =
catch-throw for achieving something like this, but that is not the =
point.

Catch-throw?  I remember reading about that but I'll bet it is one of =
the least used parts of Ruby.

The return keyword in a block or in a simple proc (but not in a lambda) =
always returns from the method in which it is lexically embedded.  In =
your example this means that 'return' is associated with the method =
render_and_return.  If you invoke the proc returned by =
render_and_return, you get an error because the associated method is not =
active when the return is executed.

Note:  This all assumes you are using Ruby 1.9.X where the proc method =
creates a simple proc and not a lambda.  If you try your example in Ruby =
1.8.X you won't get an error since you'll be calling a lambda and =
'return' in a lambda simply ends execution of the block (and *not* the =
enclosing method).

> What I'm saying is that I can't find any official reference about the =
meanings of "return", "next" or "break", for instance. Nor can I find =
the reason why such construction is not allowed.


This is discussed in _The_Ruby_Programming_Language_ by David Flanagan =
and Matz, which I consider to be more in the style of a programming =
reference manual than the more commonly referenced Pickaxe book by Dave =
Thomas (_Programming_Ruby_).  I believe you are correct that there is no =
commonly referenced online 'official' language definition.  There is the =
following ISO draft: =
<http://www.ipa.go.jp/osc/english/ruby/Ruby_final_draft_enu_20100825.pdf> =
but I don't think its description of 'return' is very helpful and the =
entire spec is out of date relative to language as defined by MRI 1.9.3.

> So, what is the reason why the proc with a return can only be called =
inside the method that created it?

Why it behaves this way gets more into the philosophy of language =
design. With your proposed semantics it isn't possible to look at the =
source code and understand that the proc will cause a return from list() =
while the current semantics of 'return' do let you look at the source =
and know what method will terminate execution because of the return.

The code you seem to want to avoid seems simple enough though.  Making =
an explicit return implicit doesn't seem like an improvement to me.  =
What is wrong with:

def list
  if allowed?
     render view: 'list'
  else
     render view: 'not_allowed'
  end
end

or

def list
  view =3D allowed? ? 'list' : 'not_allowed'
  render view: view
end



Gary Wright=