```Hi --

On Tue, 1 Aug 2006, Just Another Victim of the Ambient Morality wrote:

>
> <dblack / wobblini.net> wrote in message
> news:Pine.LNX.4.64.0608010845050.8390 / rubypal.com...
>>
>> You could say, though, that when you do this:
>>
>>   def x
>>     a = 1
>>     puts a
>>   end
>>
>>   def y
>>     x
>>   end
>>
>> you're calling x from your method y, and x has access to local
>> variables not defined in y, so x must be a closure.
>
>    Now you're narrowly construing my statement to a ludicrous degree.

I'm just discussing the topic at hand, I think.  It's really not about
this or that statement; I just like to examine things like this.

> There is context to what I said, you know?
>    In your example, method "x" has access to variable "a" because that
> variable is in its own context, not its _enclosing_ context.  This is a
> better example:
>
> a = 1
> def x
>    puts a
> end
>
> def y
>    x
> end
>
>
>    Then x _will_ be a closure but, then again, we already knew this...

But the a inside x and the a outside x are unrelated.  Method
definition blocks (with def) aren't closures.

>>>> It comes down to the fact that blocks are syntactic constructs, while
>>>> Procs are first-class objects.
>>>
>>>    I'm not sure why this has anything to do with anything...
>>
>> Consider an if statement:
>>
>>   y = 1
>>   if x
>>     y
>>   end
>>
>> The code in the middle is flat, as regards scope.  Furthermore, you
>> can't do anything with it; you can't send that chunk of code
>> somewhere, open it up, and find y.  It's just an expression or
>> statement among other expressions or statements.
>>
>> A code block has one foot in that camp.  When you see:
>>
>>   a = 10
>>   [1,2,3].each {|x| puts x * a }
>>
>> you're seeing, in a sense, a flat scope -- that is, the variable a
>> just gets used, as it might if it were in an if statement.
>
>    That's the whole point of closures.  It looks like variable "a" "just
> gets used," even though the process of it being used is quite complex.
>    If I understand what you mean by "flat," then it isn't flat.  It only
> _looks_ flat.

Right -- see the "other parts of the story", below.

>    Is this an example of "flat" scope?

Yes.

> a = "foo"
> b = a + "bar"
> puts b
>
>
>    It may look "flat" but scopes have come and gone.

I only see one local scope there.  Where do you see others?

>    Your example took a block and sent it to the method "each," which has
> it's own scope, where the block would have ordinarily had no hope of
> accessing the variable "a" except that it was a closure...

The part I'm not convinced of is "sent".  It provided a code block,
but it didn't send it.

>> That's only part of the story, though.  The other parts are, first,
>> that variables created inside the block are not in scope when the
>> block exits (so its scope is definitely not flat); and, second, the
>> fact that it's so easy to convert a block to a Proc that blocks feel
>> like first-class objects, even though they aren't.
>
>    I'm not certain that the other parts of "the story" are relevant.

See above; it's just different ways of looking at a block, or ways of
looking at different characteristics of a block.

>    Incidentally, having variables created inside the block be in scope when
> the block exits is planned for Ruby2.  Indeed, if memory serves me, it is
> Matz's "most regretting" design decision that it doesn't already do this...
> So, I guess it will then be "flat."
>    Personally, I look forward to this feature...

I'm among the few that like it the way it is, but I think we're on the
losing end of this decision-making process for 2.0 :-)

David

--
http://www.rubypowerandlight.com => Ruby/Rails training & consultancy
----> SEE SPECIAL DEAL FOR RUBY/RAILS USERS GROUPS! <-----
http://dablog.rubypal.com        => D[avid ]A[. ]B[lack's][ Web]log
http://www.manning.com/black     => book, Ruby for Rails
http://www.rubycentral.org       => Ruby Central, Inc.

```