Re: Down with Upvalues

[ramsdell@... (John D. Ramsdell)]

> You mix scope with accessibility.

...

Edgar,

The purpose of scoping rules is to define accessibility.
Look at the FOLDOC definition of lexical scoping.

     In a lexically scoped language, the scope of an identifier is
     fixed at compile-time to be the smallest block (begin/end or
     function/procedure body) containing the identifier's
     declaration. This means that an identifier declared in some block
     is only accessible within that block and from procedures declared
     within it.

It defines lexical scoping by describing when and were a variable is
accessible.  Accessibility is what scoping is all about.

John

Edgar Toernig <froese@gmx.de> writes:

> "John D. Ramsdell" wrote:
> > 
> > Your example show code that demonstrates nested scoping, but the
> > following code shows that Lua variables lack nested scope.
> > 
> > 1.     function addn(x)
> > 2.       function sum(y)
> > 3.         return x+y      -- illegal reference to x
> > 4.       end
> > 5.       return sum
> > 6.     end
> > 7.     print((addn(3))(1))
> > 
> > If the variable x had nested scope, the scope of variable x would be
> > delimited by the function/end keyword pair.  It would start at line 2,
> > and continue until line 5.  With nested scoping, the reference to
> > varible x on line 3 would be legal.
> 
> You mix scope with accessibility.  The scope of x starts at line 1
> and ends at line 6.  You get a compile time error just because Lua
> has nested lexical scope.  When seeing the use of the variable x in
> line 3 the compiler decides (based on nested lexical scope rules)
> that the declaration of x in line 1 has to be taken.  But because
> this access is not allowed in current implementation it issues an
> error message.  If Lua hadn't nested scope the compiler would most
> likely have chosen some other declaration of x (i.e. global x or an
> implied declaration of x local to sum) and would not have issued an
> error message.
> 
> Over and out, ET.