Some ideas

[Sokolov Yura <falcon@...>]

Excuse my English.
Some ideas about improving Lua.

0. Why Table.flags type is lu_byte(unsigned char)? We have 17
metamethods. Should it be unsigned short int instead? Then we cache 16
metamethods. On x86 there is no drawback having it unsigned short int
instead of unsigned char(due to the alignment).

1. Let user data to store TValue and then mark it during GC.
  Such userdata should have the __mark "method" in metatable to react on
 mark_event(as analogy of gc_event)

  Marking is made by calling markvalue macros from lgc.c for every 
stored TValue. MarkFunction should have signature int ...(global_State* 
g, GCObject* g).

  Using of TValue should be restricted by:
        a.  copying from/to lua stack (and clearing - setting to a nil)
	b.  type recognition (by macroses ttis*(o) from lobject.h)
	c.  accessing to scalar values (nil, boolean, number, but not
	         strings) (don't allow to change type, i think)
	  (macroses nvalue(o), bvalue(o), setnvalue(obj, x),
           setbvalue(obj,x), setnilvalue(obj))  (i think it is optional)
	b.  dereferencing userdata and lightuserdata(macrosses rawuvalue
           and pvalue) (it is main usecase)

  All other operations possible only using lua stack.

  Benefits:
    -  http://lua-users.org/lists/lua-l/2006-05/msg00075.html - this
       could be implemented without using of environment table - i think
       there are should be great space gain. (and gc speed)
    -  another variants of speed+space improving
    -  implementing alternative data structures (reusing existent)
       (linked lists, queue(for threading),
         hashtables ala python/ruby, etc)

  Drawbacks:
    -  opening implementation details to programmer (lua is great in
       hiding details, and i really respect it) => more error prone
       using of Lua (but i think it would not widely used, so those
       who need it will be more careful)
    -  + <10 lines of code (I think, no more)
    -  big refactoring of headers
       (new user accessable header "lua_usergc.h"?)
    -  introducing new cfunction type:
         typedef int(*lua_MarkFunction)(global_State *g, GCObject *o);
       and possibly new lua type (markfunction) - but we could store
       reference just in lightuserdata.

   It is a little change in codebase, but great improvement in
  extendability of lua.

2. Let multindex syntax t[a,b,c] and improving index and newindex events 
to this version:


function gettable_event (table, key, ...)
  local h
  if type(table) == "table" then
    if select(#, ...)==0 then
    	local v = rawget(table, key)
    	if v ~= nil then return v end
    end
    h = metatable(table).__index
    if h == nil then return nil end
  else
    h = metatable(table).__index
    if h == nil then
      error("...");
    end
  end
  if type(h) == "function" then
    return h(table, key, ...)      -- call the handler
  else return h[key, ...]          -- or repeat operation on it
  end
end

function settable_event (table, key, ...)
  local h
  if type(table) == "table" then
    if select(#, ...)==1 then
      local value = v
      local v = rawget(table, key)
      if v ~= nil then rawset(table, key, value); return end
      h = metatable(table).__newindex
      if h == nil then rawset(table, key, value); return end
    else
      h = metatable(table).__newindex
      if h == nil then error("..."); return end
    end
  else
    h = metatable(table).__newindex
    if h == nil then
      error("...");
    end
  end
  if type(h) == "function" then
    return h(table, key, ....)    -- call the handler
  else
	local t = {...}; value = t[#t]; table.remove(t);
            -- in c this should be noop
	h[key, unpack(t)] = value       -- or repeat operation on it
  end
end

Benefits:
   - NumLua, i think
   - access to ranges
	(as in Ruby:
	irb:001:0> a = [1,2,3,4,5]
        => [1,2,3,4,5]
        irb:002:0> a[2,4]
        => [3,4,5])
Drawbacks:
   - a bit slower whole execution
   - changes to the compiller
   - big refactor of gettable and settable.

If you think this ideas worth, i will try to implement it.
#1 would not be too hard, but #2 is difficult for me, but i could try.

This changes should not break existing code (for 5.1), i think.