From: Yuh-Ruey Chen <maian330@...>
Date: 2008-11-02T07:08:51+09:00
Subject: Re: How to access to local variables in enclosing scopes?

On Nov 1, 5:03 am, Mike Gold <mike.gold.4...@gmail.com> wrote:
> Yuh-Ruey Chen wrote:
> >> But then you've missed out on the advantage of lexical local variables.
> >> What you propose takes the "lexical" out of "lexical scope". It is just
> >> nested variables which are visible from other scopes.
>
> > No, what I am proposing is a mechanism for lexical scope. This is what
> > I mean with that |scope.x| - treat x as if it were from an enclosing
> > scope.
>
> I understand what you are proposing.  It cannot be called a mechanism
> for lexical scope, because it's fundamentally inconsistent with the
> term.  A 'def' method definition has a _different_ scope, not a nested
> scope.  _By definition_, a scope cannot refer to lexical variables in a
> different scope.  That's the whole point of lexical local variables.
>
> There's a reason why Lisp moved to lexical scoping and never looked
> back.  Ruby uses lexical scoping for the exact same reason.  It is
> better.

I'm not following you. Ruby uses lexical scope? AFAIK, it only does
that constants and not local variables.

My point is that if |def| were to use lexical scope with regards to
local variables, then there needs to be some sort of mechanism to
access those local variables. It could be:

scope.x

or

hey_ruby_interpreter__the_following_identifiers_are_not_methods__they_are_local_variables_from_parent_scopes
x

> Again, just make your shared data explicit, like the SHARED struct in
> the previous example.  That's all.  Others will be glad you were upfront
> about what is shared.  When debugging, it's valuable to know at a glance
> what variables can possibly affect state.
>
> Think of the alternative.  When tracking down a bug, under your proposal
> you would have to check -- recursively! -- for scope.x references to
> each and every variable which exists.

Nope, you're clearly not understanding my proposal. |def| currently
introduces a new empty scope. I'm saying that if |def| were changed so
that when first read by the interpreter, it looks at all the local
variables that could be accessed lexically if |def| had lexical scope,
and that within the |def|, there would be a mechanism for accessing
those local variables.

> >> > Except I do NOT want x to be globally accessible. I just want to to be
> >> > accessible be child scopes. If I wanted it to be globally accessible,hey_ruby_the_following_vars_are_not_methods__they_are_from_parent_scopes
> >> > then I would just use global variables.
>
> >> So don't make it global, as in the Top example above.
>
> > But they are not local variables. Local vars for a function are
> > created each time the function is called. Having access to those local
> > vars outside of the function makes no sense at all.
>
> This paragraph does not make sense to me.  In my example, the SHARED
> OpenStruct instance is not a local variable.  It starts with a capital
> letter.

Yes, I'm aware that it's not a local variable. I'm saying that using
constants like that cannot adequately simulate the semantics and
restrictions of local variables.