[grammarians] variable scoping

Terence Parr parrt at cs.usfca.edu
Sun Nov 27 16:02:50 EST 2005


On Nov 27, 2005, at 12:54 PM, MenTaLguY wrote:

> On Sun, 2005-11-27 at 10:56 -0800, Terence Parr wrote:
>> Good to know.  So a scope is a lexical scope of the method?  For the
>> random code I type outside of a method, what "method" is it a part  
>> of?
>
> Well, there is an enclosing file-level scope for local variables in  
> that
> case which gets used when you're outside a class or method definition.
>
>> Where is there an informal description of scoping rules and general
>> syntax?
>
> I've got a bad feeling we're writing it.

;)  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.

> Files, class/module definitions, and method definitions all have their
> own independent scopes for local variables.  A method definition  
> cannot
> see local variables in its enclosing class/module definition, and a
> class/module definition cannot see local variables in any enclosing
> things.

cool.

> 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.  A

This is something python can't do, right?  I.e., no general blocks?

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

really?  wow.

> No other constructs (including begin/if/case/rescue/etc...) affect  
> local
> variable scoping.
>
> The scoping rules for self, @instance_variables_like_this,
> @@class_variables_like_this, and CONSTANTS_LIKE_THIS, are different  
> but
> (I believe) are not relevent to parsing.

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

> Basically though, as far as local variable scoping rules go, they are
> mostly reflected in the AST.
>
>  (scope ...) indicates a "blank slate" scope for local variables;
> variables from the parent node (if applicable) are not visible  
> within it
>
>  (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?

> The following ruby fragment:
>
>         foo = bar
>
>         class Eek
>           baz = zum
>
>           def meep( tot )
>             zot = um
>             foo.each { |plok| la = 32 }
>           end
>         end
>
> parses as:
>
>         (lasgn foo
>           (vcall bar))
>         (class Eek
>           (scope
>             (block
>               (lasgn baz
>                 (vcall zum))
>               (defn meep
>                 (scope
>                   (block
>                     (args tot)
>                     (lasgn zot
>                       (vcall um))
>                     (iter
>                       (call
>                         (vcall foo) each)
>                       (dasgn_curr plok)
>                       (block
>                         (dasgn_curr la)

why the repeated assign?

>                         (dasgn_curr la
>                           (lit #<32>))))))))))
>
> Obviously there is also some evaluator junk in there which has  
> little to
> do with syntax, though.

That tree makes sense essentially...

> n.b. the current dump-ruby.rb strips the outermost [file-level] (scope
> (block ... )) in its output, which now that I think about it is  
> probably
> wrong.  But I don't know what the actual parser does.

no worries.
Ter


More information about the Rubygrammar-grammarians mailing list