upvals in Lua bytecode

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

upvals in Lua bytecode

Xingzhi Pan
Hi,

I'm using luac -l to observe the bytecode of the following Lua source:

 1 function fo (i)
 2     uv = 0
 3     function fi1 ()
 4         print(uv)
 5         uv = 1
 6         print(uv)
 7     end
 8     function fi2 ()
 9         print(uv)
10         uv = 2
11         print(uv)
12     end
13     if i == 1 then return fi1 end
14     if i == 2 then return fi2 end
15 end
16

And this is what I get:

main <../upval.lua:0,0> (3 instructions, 12 bytes at 0x100101050)
0+ params, 2 slots, 0 upvalues, 0 locals, 1 constant, 1 function
        1       [15]    CLOSURE         0 0     ; 0x1001011f0
        2       [1]     SETGLOBAL       0 -1    ; fo
        3       [15]    RETURN          0 1

function <../upval.lua:1,15> (15 instructions, 60 bytes at 0x1001011f0)
1 param, 2 slots, 0 upvalues, 1 local, 6 constants, 2 functions
        1       [2]     LOADK           1 -2    ; 0
        2       [2]     SETGLOBAL       1 -1    ; uv
        3       [7]     CLOSURE         1 0     ; 0x1001015c0
        4       [3]     SETGLOBAL       1 -3    ; fi1
        5       [12]    CLOSURE         1 1     ; 0x1001017c0
        6       [8]     SETGLOBAL       1 -4    ; fi2
        7       [13]    EQ              0 0 -5  ; - 1
        8       [13]    JMP             2       ; to 11
        9       [13]    GETGLOBAL       1 -3    ; fi1
        10      [13]    RETURN          1 2
        11      [14]    EQ              0 0 -6  ; - 2
        12      [14]    JMP             2       ; to 15
        13      [14]    GETGLOBAL       1 -4    ; fi2
        14      [14]    RETURN          1 2
        15      [15]    RETURN          0 1

function <../upval.lua:3,7> (9 instructions, 36 bytes at 0x1001015c0)
0 params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
        1       [4]     GETGLOBAL       0 -1    ; print
        2       [4]     GETGLOBAL       1 -2    ; uv
        3       [4]     CALL            0 2 1
        4       [5]     LOADK           0 -3    ; 1
        5       [5]     SETGLOBAL       0 -2    ; uv
        6       [6]     GETGLOBAL       0 -1    ; print
        7       [6]     GETGLOBAL       1 -2    ; uv
        8       [6]     CALL            0 2 1
        9       [7]     RETURN          0 1

function <../upval.lua:8,12> (9 instructions, 36 bytes at 0x1001017c0)
0 params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
        1       [9]     GETGLOBAL       0 -1    ; print
        2       [9]     GETGLOBAL       1 -2    ; uv
        3       [9]     CALL            0 2 1
        4       [10]    LOADK           0 -3    ; 2
        5       [10]    SETGLOBAL       0 -2    ; uv
        6       [11]    GETGLOBAL       0 -1    ; print
        7       [11]    GETGLOBAL       1 -2    ; uv
        8       [11]    CALL            0 2 1
        9       [12]    RETURN          0 1

So my question is that for inner functions fi1 and fi2, why GETGLOBAL
and SETGLOBAL, rather than GETUPVAL and SETUPVAL, are used?  Isn't uv
an upvalue?

Also, it shows "0 upvalues" for these 2 functions, where I thought
should be one.

Thanks,
Xingzhi 'Harry' Pan

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Javier Guerra Giraldez
On Thu, Jun 2, 2011 at 12:19 AM, Xingzhi Pan <[hidden email]> wrote:
> So my question is that for inner functions fi1 and fi2, why GETGLOBAL
> and SETGLOBAL, rather than GETUPVAL and SETUPVAL, are used?  Isn't uv
> an upvalue?

no, uv is a global.

it wasn't declared with 'local' at the outermost fo() function

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

François Perrad
In reply to this post by Xingzhi Pan


2011/6/2 Xingzhi Pan <[hidden email]>
Hi,

I'm using luac -l to observe the bytecode of the following Lua source:

 1 function fo (i)
 2     uv = 0
 3     function fi1 ()
 4         print(uv)
 5         uv = 1
 6         print(uv)
 7     end
 8     function fi2 ()
 9         print(uv)
10         uv = 2
11         print(uv)
12     end
13     if i == 1 then return fi1 end
14     if i == 2 then return fi2 end
15 end
16

And this is what I get:

main <../upval.lua:0,0> (3 instructions, 12 bytes at 0x100101050)
0+ params, 2 slots, 0 upvalues, 0 locals, 1 constant, 1 function
       1       [15]    CLOSURE         0 0     ; 0x1001011f0
       2       [1]     SETGLOBAL       0 -1    ; fo
       3       [15]    RETURN          0 1

function <../upval.lua:1,15> (15 instructions, 60 bytes at 0x1001011f0)
1 param, 2 slots, 0 upvalues, 1 local, 6 constants, 2 functions
       1       [2]     LOADK           1 -2    ; 0
       2       [2]     SETGLOBAL       1 -1    ; uv
       3       [7]     CLOSURE         1 0     ; 0x1001015c0
       4       [3]     SETGLOBAL       1 -3    ; fi1
       5       [12]    CLOSURE         1 1     ; 0x1001017c0
       6       [8]     SETGLOBAL       1 -4    ; fi2
       7       [13]    EQ              0 0 -5  ; - 1
       8       [13]    JMP             2       ; to 11
       9       [13]    GETGLOBAL       1 -3    ; fi1
       10      [13]    RETURN          1 2
       11      [14]    EQ              0 0 -6  ; - 2
       12      [14]    JMP             2       ; to 15
       13      [14]    GETGLOBAL       1 -4    ; fi2
       14      [14]    RETURN          1 2
       15      [15]    RETURN          0 1

function <../upval.lua:3,7> (9 instructions, 36 bytes at 0x1001015c0)
0 params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
       1       [4]     GETGLOBAL       0 -1    ; print
       2       [4]     GETGLOBAL       1 -2    ; uv
       3       [4]     CALL            0 2 1
       4       [5]     LOADK           0 -3    ; 1
       5       [5]     SETGLOBAL       0 -2    ; uv
       6       [6]     GETGLOBAL       0 -1    ; print
       7       [6]     GETGLOBAL       1 -2    ; uv
       8       [6]     CALL            0 2 1
       9       [7]     RETURN          0 1

function <../upval.lua:8,12> (9 instructions, 36 bytes at 0x1001017c0)
0 params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
       1       [9]     GETGLOBAL       0 -1    ; print
       2       [9]     GETGLOBAL       1 -2    ; uv
       3       [9]     CALL            0 2 1
       4       [10]    LOADK           0 -3    ; 2
       5       [10]    SETGLOBAL       0 -2    ; uv
       6       [11]    GETGLOBAL       0 -1    ; print
       7       [11]    GETGLOBAL       1 -2    ; uv
       8       [11]    CALL            0 2 1
       9       [12]    RETURN          0 1

So my question is that for inner functions fi1 and fi2, why GETGLOBAL
and SETGLOBAL, rather than GETUPVAL and SETUPVAL, are used?  Isn't uv
an upvalue?

Currently, uv is a global variable.
If you want an upvalue, you must use 'local uv = 0' line 2.

François
 

Also, it shows "0 upvalues" for these 2 functions, where I thought
should be one.

Thanks,
Xingzhi 'Harry' Pan


Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Xingzhi Pan
Oh mine, it is a bit unintuitive to leave "global" as default.  Thank
you people!

Harry

On Wed, Jun 1, 2011 at 11:49 PM, François Perrad
<[hidden email]> wrote:

>
>
> 2011/6/2 Xingzhi Pan <[hidden email]>
>>
>> Hi,
>>
>> I'm using luac -l to observe the bytecode of the following Lua source:
>>
>>  1 function fo (i)
>>  2     uv = 0
>>  3     function fi1 ()
>>  4         print(uv)
>>  5         uv = 1
>>  6         print(uv)
>>  7     end
>>  8     function fi2 ()
>>  9         print(uv)
>> 10         uv = 2
>> 11         print(uv)
>> 12     end
>> 13     if i == 1 then return fi1 end
>> 14     if i == 2 then return fi2 end
>> 15 end
>> 16
>>
>> And this is what I get:
>>
>> main <../upval.lua:0,0> (3 instructions, 12 bytes at 0x100101050)
>> 0+ params, 2 slots, 0 upvalues, 0 locals, 1 constant, 1 function
>>        1       [15]    CLOSURE         0 0     ; 0x1001011f0
>>        2       [1]     SETGLOBAL       0 -1    ; fo
>>        3       [15]    RETURN          0 1
>>
>> function <../upval.lua:1,15> (15 instructions, 60 bytes at 0x1001011f0)
>> 1 param, 2 slots, 0 upvalues, 1 local, 6 constants, 2 functions
>>        1       [2]     LOADK           1 -2    ; 0
>>        2       [2]     SETGLOBAL       1 -1    ; uv
>>        3       [7]     CLOSURE         1 0     ; 0x1001015c0
>>        4       [3]     SETGLOBAL       1 -3    ; fi1
>>        5       [12]    CLOSURE         1 1     ; 0x1001017c0
>>        6       [8]     SETGLOBAL       1 -4    ; fi2
>>        7       [13]    EQ              0 0 -5  ; - 1
>>        8       [13]    JMP             2       ; to 11
>>        9       [13]    GETGLOBAL       1 -3    ; fi1
>>        10      [13]    RETURN          1 2
>>        11      [14]    EQ              0 0 -6  ; - 2
>>        12      [14]    JMP             2       ; to 15
>>        13      [14]    GETGLOBAL       1 -4    ; fi2
>>        14      [14]    RETURN          1 2
>>        15      [15]    RETURN          0 1
>>
>> function <../upval.lua:3,7> (9 instructions, 36 bytes at 0x1001015c0)
>> 0 params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
>>        1       [4]     GETGLOBAL       0 -1    ; print
>>        2       [4]     GETGLOBAL       1 -2    ; uv
>>        3       [4]     CALL            0 2 1
>>        4       [5]     LOADK           0 -3    ; 1
>>        5       [5]     SETGLOBAL       0 -2    ; uv
>>        6       [6]     GETGLOBAL       0 -1    ; print
>>        7       [6]     GETGLOBAL       1 -2    ; uv
>>        8       [6]     CALL            0 2 1
>>        9       [7]     RETURN          0 1
>>
>> function <../upval.lua:8,12> (9 instructions, 36 bytes at 0x1001017c0)
>> 0 params, 2 slots, 0 upvalues, 0 locals, 3 constants, 0 functions
>>        1       [9]     GETGLOBAL       0 -1    ; print
>>        2       [9]     GETGLOBAL       1 -2    ; uv
>>        3       [9]     CALL            0 2 1
>>        4       [10]    LOADK           0 -3    ; 2
>>        5       [10]    SETGLOBAL       0 -2    ; uv
>>        6       [11]    GETGLOBAL       0 -1    ; print
>>        7       [11]    GETGLOBAL       1 -2    ; uv
>>        8       [11]    CALL            0 2 1
>>        9       [12]    RETURN          0 1
>>
>> So my question is that for inner functions fi1 and fi2, why GETGLOBAL
>> and SETGLOBAL, rather than GETUPVAL and SETUPVAL, are used?  Isn't uv
>> an upvalue?
>
> Currently, uv is a global variable.
> If you want an upvalue, you must use 'local uv = 0' line 2.
>
> François
>
>>
>> Also, it shows "0 upvalues" for these 2 functions, where I thought
>> should be one.
>>
>> Thanks,
>> Xingzhi 'Harry' Pan
>>
>
>



--
Pan, Xingzhi
http://www.panxingzhi.net

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Geoff Leyland
On 2/06/2011, at 7:13 PM, Xingzhi Pan wrote:

> Oh mine, it is a bit unintuitive to leave "global" as default.


Local by default is worse: http://lua-users.org/wiki/LocalByDefault


Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Reuben Thomas-5
On 2 June 2011 08:19, Geoff Leyland <[hidden email]> wrote:
> On 2/06/2011, at 7:13 PM, Xingzhi Pan wrote:
>
>> Oh mine, it is a bit unintuitive to leave "global" as default.
>
>
> Local by default is worse: http://lua-users.org/wiki/LocalByDefault

I've flip-flopped on this question, but have ended up in the "local by
default" camp. It simply causes fewer problems (not "no problems")
than the reverse, and simply laying some Lua side-by-side with
equivalent Python shows this: the Lua contains many "local"s, whereas
the Python contains almost no "outer"s.

--
http://rrt.sc3d.org

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Miles Bader-2
Reuben Thomas <[hidden email]> writes:
> I've flip-flopped on this question, but have ended up in the "local by
> default" camp. It simply causes fewer problems (not "no problems")
> than the reverse, and simply laying some Lua side-by-side with
> equivalent Python shows this: the Lua contains many "local"s, whereas
> the Python contains almost no "outer"s.

There are other, better, options than those two though, e.g., "error by default."

-miles

--
Education, n. That which discloses to the wise and disguises from the foolish
their lack of understanding.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Reuben Thomas-5
On 2 June 2011 08:32, Miles Bader <[hidden email]> wrote:
> Reuben Thomas <[hidden email]> writes:
>> I've flip-flopped on this question, but have ended up in the "local by
>> default" camp. It simply causes fewer problems (not "no problems")
>> than the reverse, and simply laying some Lua side-by-side with
>> equivalent Python shows this: the Lua contains many "local"s, whereas
>> the Python contains almost no "outer"s.
>
> There are other, better, options than those two though, e.g., "error by default."

That's crazy talk! You'll be suggesting that Lua should be
statically-typed next. Seriously, horses for courses, and "error by
default" would not fit with Lua.

--
http://rrt.sc3d.org

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Geoff Leyland
In reply to this post by Reuben Thomas-5
On 2/06/2011, at 7:27 PM, Reuben Thomas wrote:

> On 2 June 2011 08:19, Geoff Leyland <[hidden email]> wrote:
>> On 2/06/2011, at 7:13 PM, Xingzhi Pan wrote:
>>
>>> Oh mine, it is a bit unintuitive to leave "global" as default.
>>
>> Local by default is worse: http://lua-users.org/wiki/LocalByDefault
>
> I've flip-flopped on this question, but have ended up in the "local by
> default" camp. It simply causes fewer problems (not "no problems")
> than the reverse, and simply laying some Lua side-by-side with
> equivalent Python shows this: the Lua contains many "local"s, whereas
> the Python contains almost no "outer"s.


Is "outer" new?  I almost immediately got scope paranoia using Python, but that was a long time ago.  I hardly ever get tripped up by global by default if I do its easily fixed.  Can you work around local by default without outer?

In any case, if you want an edit, then "Local by default is also problematic"; if you're interested, I'd pick nothing by default; and, since the list's been here before, sorry for the noise, I was just to pointing to the wiki.

Cheers,
Geoff
Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Reuben Thomas-5
On 2 June 2011 08:39, Geoff Leyland <[hidden email]> wrote:
>
> Is "outer" new?

PEP 3104, 12th October 2006.

> I almost immediately got scope paranoia using Python, but that was a
> long time ago.

Since Python is local by default, I assume the above is to be
contrasted with the following:

> I hardly ever get tripped up by global by default if I do its easily fixed.

And hence you're saying neither is a big problem?

> Can you work around local by default without outer?

As Mike Pall points out on the wiki page, local-by-default without
outer or some other mechanism prevents access to variables in
non-global scopes lexically outside the current one. As the PEP says
of the situation before outer: "Currently, Python code can refer to a
name in any enclosing scope, but it can only rebind names in two
scopes: the local scope (by simple assignment) or the module-global
scope (using a global declaration)."

--
http://rrt.sc3d.org

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Miles Bader-2
In reply to this post by Reuben Thomas-5
On Thu, Jun 2, 2011 at 7:37 AM, Reuben Thomas <[hidden email]> wrote:
>> There are other, better, options than those two though, e.g., "error by default."
>
> That's crazy talk! You'll be suggesting that Lua should be
> statically-typed next.

Naw....

> Seriously, horses for courses, and "error by default" would not fit with Lua.

Sure it would.  Maybe you (etc) have a different opinion, but I think
I've done enough Lua programming to have a pretty good feel for what
works, and I'd _love_ error-by-default.

Neither global-by-default nor local-by-default is a very good choice
for any but the most trivial programs, and most of the stuff I write
in Lua either tends to be over that threshold, or is essentially all
top-level assignments, with few functions.

-Miles

--
Cat is power.  Cat is peace.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Reuben Thomas-5
On 2 June 2011 08:49, Miles Bader <[hidden email]> wrote:
> On Thu, Jun 2, 2011 at 7:37 AM, Reuben Thomas <[hidden email]> wrote:
>
>> Seriously, horses for courses, and "error by default" would not fit with Lua.
>
> Sure it would.  Maybe you (etc) have a different opinion, but I think
> I've done enough Lua programming to have a pretty good feel for what
> works,

The very fact that no other common scripting language does this is a
bad sign, but in the case of Lua there's the explicit reason that it's
meant to work for data description (Lua equivalent of JON), things
like:

server = "foo.bar.com"
port = 25

which break if every variable has to be declared.

--
http://rrt.sc3d.org

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Miles Bader-2
On Thu, Jun 2, 2011 at 8:07 AM, Reuben Thomas <[hidden email]> wrote:
> The very fact that no other common scripting language does this is a
> bad sign

Most common scripting languages are a horror-freak-show of bad design decisions.

> but in the case of Lua there's the explicit reason that it's
> meant to work for data description (Lua equivalent of JON), things
> like:
>
> server = "foo.bar.com"
> port = 25

I didn't think it was necessary to say so explicitly, but I would make
an exception for _top-level_ declarations.

I agree that it's Lua's background as a data-description language that
probably led to the use of global-by-default, but I don't think it's a
good design for Lua as it's used today.

-miles

--
Cat is power.  Cat is peace.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Florian Weimer
In reply to this post by Reuben Thomas-5
* Reuben Thomas:

> On 2 June 2011 08:39, Geoff Leyland <[hidden email]> wrote:
>>
>> Is "outer" new?
>
> PEP 3104, 12th October 2006.

It's actually "nonlocal".

>> I almost immediately got scope paranoia using Python, but that was a
>> long time ago.
>
> Since Python is local by default,

It's more complicated than that.

Python has function-scoped local variables (just like Javascript).
Assignment to a variable anywhere in a function makes it
function-scoped, for the entire function.  Without such an assignment,
variable references are global.

In contrast, in most languages, local variables are block-scoped.  The
Python approach does not make much sense for them.  Let's assume you
want to initialize x based on some condition.  In Python, you can
write:

  if condition:
      x = f1()
  else:
      x = f2()

If x is not of function scope, then this has not the intended effect.
You'd actually have to write this instead:

  x = (function()
          if cond then
             return f1()
          else
             return f2()
          end)()

Anyway, to me, the local-vs-global discussion is tied to the module
system and some sort of phase distinction in the compiler.  If there
was a way to plug into global name lookup in the compiler, we could
accurately describe to the compiler what global variables exist, and
the compiler could error out for unknown global variables.  It might
even be possible to compile expressions such as string.byte to a
constant reference in the byte code, so that the need for the
"local byte = string.byte" pattern goes away.

But in the end, it's more of a tools issue.  Microsoft seems to have a
Javascript editor which gets this right for Javascript---they execute
the code in a sandbox and collect symbol information from the result.
Thus, they can warn about references to non-existing variables in the
editor in the editor.  There are several projects to implement similar
functionality for Lua.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Tony Finch
In reply to this post by Miles Bader-2
Miles Bader <[hidden email]> wrote:
>
> There are other, better, options than those two though, e.g., "error by default."

Yes.

There are quite a few options in this design space, most of which are not
very Lua-ish, e.g. using shorter keywords (my/our instead of
local/global), use sigils to indicate scope ($v for _ENV.v, @v for
self.v), use v := e as an abbreviation for local v = e.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Tony Finch
In reply to this post by Reuben Thomas-5
Reuben Thomas <[hidden email]> wrote:
>
> The very fact that no other common scripting language does this is a
> bad sign,

Yeah, no-one uses Perl.

> but in the case of Lua there's the explicit reason that it's
> meant to work for data description (Lua equivalent of JON), things
> like:
>
> server = "foo.bar.com"
> port = 25
>
> which break if every variable has to be declared.

Lua could perhaps switch on error-by-default mode the first time it sees a
"global" declaration.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Tony Finch
In reply to this post by Florian Weimer
Florian Weimer <[hidden email]> wrote:
>
> Anyway, to me, the local-vs-global discussion is tied to the module
> system and some sort of phase distinction in the compiler.  If there
> was a way to plug into global name lookup in the compiler, we could
> accurately describe to the compiler what global variables exist, and
> the compiler could error out for unknown global variables.

I think this is over-ambitious. You can get a lot of benefit from just
checking that variables are declared before use within a module. It then
becomes easy to find which global variables exist using grep - though it
gets interesting if you play games with function environments.

> It might even be possible to compile expressions such as string.byte to
> a constant reference in the byte code, so that the need for the "local
> byte = string.byte" pattern goes away.

LuaJIT does that, but it requires analysis to prove that string.byte is
not assigned to directly or via an alias.

Tony.
--
f.anthony.n.finch  <[hidden email]>  http://dotat.at/
Rockall, Malin, Hebrides: South 5 to 7, occasionally gale 8 at first in
Rockall and Malin, veering west or northwest 4 or 5, then backing southwest 5
or 6 later. Rough or very rough. Occasional rain. Moderate or good,
occasionally poor.

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Pierre Chapuis
In reply to this post by Tony Finch
On Thu, 2 Jun 2011 11:39:41 +0100, Tony Finch wrote:

> Lua could perhaps switch on error-by-default mode the first time it
> sees a
> "global" declaration.

Maybe it could be optional but still more explicit,
with something like Perl Strictures?

--
Pierre 'catwell' Chapuis

Reply | Threaded
Open this post in threaded view
|

Re: upvals in Lua bytecode

Luiz Henrique de Figueiredo
In reply to this post by Florian Weimer
> If there was a way to plug into global name lookup in the compiler, we
> could accurately describe to the compiler what global variables exist

See a patch in
        http://lua-users.org/lists/lua-l/2006-10/msg00206.html

This has often been mentioned here before. See these threads:
        http://lua-users.org/lists/lua-l/2010-07/msg00512.html
        http://lua-users.org/lists/lua-l/2009-11/msg01020.html
        http://lua-users.org/lists/lua-l/2008-02/msg00814.html
        http://lua-users.org/lists/lua-l/2007-08/msg00409.html

> It might even be possible to compile expressions such as string.byte
> to a constant reference in the byte code, so that the need for the
> "local byte = string.byte" pattern goes away.

This is not hard to do with token filters.

Reply | Threaded
Open this post in threaded view
|

enumerating local vars in C

Jörg Walter
I'm enumerating local vars with:

     lua_Debug debug_info;
     int level = 0;
     while (lua_getstack(ls, level++, &debug_info) == 1)
     {
         const char* tmp = 0;
         int i = 1;
         while ((tmp = lua_getlocal(ls, &debug_info, i++)) != NULL)
         {
            //.....

             lua_pop(ls, 1);
         }
     }

my lua-script is:

        local val = nil

        local val = exampleGet()

        print(val)

when enumerating on the 3. line, I get two variables 'val', one nil and
one number. why is that?

Am 02.06.2011 13:45, schrieb Luiz Henrique de Figueiredo:

>> If there was a way to plug into global name lookup in the compiler, we
>> could accurately describe to the compiler what global variables exist
>
> See a patch in
> http://lua-users.org/lists/lua-l/2006-10/msg00206.html
>
> This has often been mentioned here before. See these threads:
> http://lua-users.org/lists/lua-l/2010-07/msg00512.html
> http://lua-users.org/lists/lua-l/2009-11/msg01020.html
> http://lua-users.org/lists/lua-l/2008-02/msg00814.html
> http://lua-users.org/lists/lua-l/2007-08/msg00409.html
>
>> It might even be possible to compile expressions such as string.byte
>> to a constant reference in the byte code, so that the need for the
>> "local byte = string.byte" pattern goes away.
>
> This is not hard to do with token filters.
>
>

12