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 _______________________________________________ Rubygrammar-grammarians mailing list [EMAIL PROTECTED] http://rubyforge.org/mailman/listinfo/rubygrammar-grammarians
