Re: [Proposal] _LOCAL was: Re: how to call a local function by its name?

[Coda Highland <chighland@...>]

On Mon, Jun 8, 2015 at 3:14 PM, Soni L. <fakedme@gmail.com> wrote:
>
>
> On 08/06/15 06:40 PM, Coda Highland wrote:
>>
>> On Mon, Jun 8, 2015 at 2:09 PM, Soni L. <fakedme@gmail.com> wrote:
>>>
>>>
>>> On 08/06/15 06:05 PM, Soni L. wrote:
>>>
>>> I wish you could access your own locals with an _LOCAL[idx] that would be
>>> faster than debug.getlocal...
>>>
>>> Not sure how that'd work if you local x = _LOCAL, or called a function
>>> with
>>> _LOCAL...
>>>
>>> Actually I do know, _LOCAL tables would be like any other tables, but
>>> heavily optimized for this kind of stuff, and it'd be part of the
>>> function's
>>> call stack entry thingy. The GC can take care of the rest.
>>
>> function locals()
>> return setmetatable({ [0]={} }, {
>>      __index = function(t, k)
>>              local ki = t[0][k]
>>              assert(ki, "attempt to read nonexistent local")
>>              local ln, lv = debug.getlocal(2, ki)
>>              assert(ln == k, "inconsistent state")
>>              return ln
>>          end,
>>      __newindex = function(t, k, v)
>>              local ki = t[0][k]
>>              if not ki then
>>                  local i = 0
>>                  while true do
>>                      i = i + 1
>>                      local ln, lv = debug.getlocal(2, i)
>>                      if ln == k then
>>                          ki = i
>>                          break
>>                      elif not ln then
>>                          break
>>                      end
>>                  end
>>                  assert(ki, "attempt to assign nonexistent local")
>>              end
>>              debug.setlocal(2, ki, v)
>>          end
>> })
>> end
>>
>> _LOCAL = locals()
>>
>> Untested... but that's about as good as you're going to get.
>>
>> /s/ Adam
>>
> Not faster than debug.getlocal, cannot be passed around, cannot be indexed
> with NUMBERS, doesn't give access to varargs... What else? (I guess the
> varargs part would be really awesome tbh, just changing varargs on the fly,
> accessing them at 0 (or at least little) cost, etc... Can debug.setlocal()
> be used to set varargs?)
>

I started working on that before you sent the e-mail with the extra
constraints on it.

Adding indexing by numbers would be near-trivially easy -- in fact I
was GOING to do that before I realized it wasn't necessary and would
just add overhead. And indexing by numbers would trivially enable
varargs.

I MIGHT be able to optimize matters a little bit further if I can
memoize _LOCAL across function invocations, but that could potentially
be fragile; there's research I'd have to do first.

Regardless, asking for better performance out of this is rather silly
-- when would you EVER be in a situation where you're not implementing
a debugger and reflection is the only answer you can come up with for
how to do something?

/s/ Adam