lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 



On 06/10/15 08:58 PM, Rena wrote:

On Tue, Oct 6, 2015 at 5:19 PM, Soni L. <fakedme@gmail.com> wrote:


On 06/10/15 06:12 PM, Rena wrote:


On Oct 6, 2015 2:50 PM, "Coda Highland" <chighland@gmail.com
<mailto:chighland@gmail.com>> wrote:

On Tue, Oct 6, 2015 at 11:01 AM, Tim Hill <drtimhill@gmail.com
<mailto:drtimhill@gmail.com>> wrote:

On Oct 5, 2015, at 3:55 PM, Soni L. <fakedme@gmail.com
<mailto:fakedme@gmail.com>> wrote:

I think load() should, in addition to _ENV, also take a list of
upvalues, which are only used when loading bytecode.

When loading bytecode _ENV is assumed to be the first upvalue,
upvalue 0, so we just need to make it varargs for the other upvalues.

This reduces the need for debug.upvaluejoin() (or w/e, setupvalue?)
when loading bytecode.

--
Disclaimer: these emails may be made public at any given time, with
or without reason. If you don't agree with this, DO NOT REPLY.




Why only when loading bytecode? Post-compilation, there is no
difference between bytecode and source code.

Source code can't (easily) refer to upvalues positionally. Source code
uses names. Varargs passed to load() don't have names.

So sure, there's no reason why the function should throw an error if
you DO pass them, but uncompiled code inside will have a hard time
interoperating with them.

/s/ Adam


Any reason the upvalues couldn't be given as a table?


Order.


--
Disclaimer: these emails may be made public at any given time, with or
without reason. If you don't agree with this, DO NOT REPLY.



How does order factor in, if the code refers to them by name? I think
I'm overlooking something.
In Rio Lua, the order is as they appear. So if a global access appears before any other upvalue access on a function, _ENV is the first upvalue. 

local u2, u3, u4, u5
function()
print(u2, u3, u4, u5) -- _ENV is the first upvalue, because "print" is actually "_ENV.print" (or "_ENV['print']") 
end

--
Disclaimer: these emails may be made public at any given time, with or without reason. If you don't agree with this, DO NOT REPLY.