Re: [Suggestion] Passing upvalues to load()

[Rena <hyperhacker@...>]

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.

-- 
Sent from my Game Boy.