[grammarians] variable scoping

[MenTaLguY]

On Sun, 2005-11-27 at 13:02 -0800, Terence Parr wrote:
> On Nov 27, 2005, at 12:54 PM, MenTaLguY wrote:
> 
> ;)  Well, i found this:
> 
> http://www.math.sci.hokudai.ac.jp/~gotoken/ruby/man/syntax.html#lexical
> 
> which seems ok.  Just bought the thomas 2nd edition (used); be here  
> in 8 days.

Ahh, good.  I vaguely remember that from my early days as a Rubyist, but
it's gotten buried in all the more up-to-date documentation (which sadly
concerns itself with only the APIs).

> > For blocks (that is, anonymous functions), variables introduced within
> > the block (this includes its parameters) are not visible outside  
> > it, but blocks still capture variables from the enclosing lexical scope.
>
> This is something python can't do, right?  I.e., no general blocks?

Not sure what you mean... python can (sort of) do lambdas with lexical
closure, but if I remember right it's awkward and explicit.  They do
(again, as I recall) get their own variable scope automatically.

> > block parameter named the same as an already visible variable will  
> > alias that variable rather than shadowing it.
> 
> really?  wow.

I believe it's a feature that will be going away in Ruby 2.

while

 blah = nil
 result = something.zopmof { |blah| ... }
 # do something with blah

is cute, it's not particularly readable; this is probably clearer:

 blah = nil
 result = something.zopmof { |value| blah = value ; ... }
 # do something with blah

The former is also not all that common; the main time I've seen it done
is with callcc.

> > (block ...) indicates a scope in which new local variables can be
> > declared by first-assignment; existing variables are inherited from  
> > the parent node (enabling lexical closure)
> 
> Wouldn't that be a dynamic scope rather than a lexical?

Er, no... visibility/scoping of local variables is lexical, not dynamic.

Maybe I'm explaining this badly. :/

> They should resolve by looking at the innermost enclosing class and  
> then upwards in mixin/inheritance, right?

Sort of.

self is the receiver of the current method, and determines how the
following are resolved.

@instance variables are specific to a particular object.

@@class variables just go up the mixin/inheritance hierarchy.

CONSTANTS do the enclosing+mixin/inheritance dance more or less like you
say, I forget the specifics.

> >                       (block
> >                         (dasgn_curr la)
> 
> why the repeated assign?
> 
> >                         (dasgn_curr la
> >                           (lit #<32>))))))))))

Hmm, good eye.  I don't know...

-mental
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://rubyforge.org/pipermail/rubygrammar-grammarians/attachments/20051127/a665cbda/attachment.bin