Re: global environment special case

[Norman Ramsey <nr@...>]

 > > Since the table data type is used so effectively to keep Lua simple and
 > > powerful, it made me wonder why use of tables wasn't extended as far as th
   e
 > > global environment.  In other words why does a programmer implementing
 > > extensions have to treat the global environment as a special case?
 > > [...]

Me too, me too :-)

 > For sure this solution is quite elegant. But I am afraid that performance 
 > is a problem. For example, the following script 
 > 
 >   a = 0
 >   local i = 1
 >   while i<=1000000 do
 >     a = a+1
 >     i = i+1
 >   end
 > 
 > runs in 1.17s in my machine. If you change it to
 > 
 >   local a = {a=0}
 >   local i = 1
 >   while i<=1000000 do
 >     a.a = a.a+1
 >     i = i+1
 >   end
 > 
 > the time goes to 1.90s.

Can you explain how much this experiment tells us?  You've added
bytecodes, etc., so I'm not surprised it's slower.  I don't think
anyone is suggesting that compiler's view or the view of compiled code
change---there should still be a distinguished global table in the Lua
state, and that table should be an *implicit* argument of bytecodes
that manipulate global variables.

I believe that what is suggested is that the API change.  That is, the
API should provide access directly to the global table, and ordinary
table functions should be usable to manipulate it.  This API change
could also be reflected in the language itself (next etc.).

 > Another problem is compatibility for tag methods (your "roughly"). The way 
 > tag methods are selected for globals is quite different from the way for 
 > tables. 

Ouch!


N