lua-users home
lua-l archive

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


D Burgess <dburgess <at> gmail.com> writes:
> 
> I have looked at the patch and I think I like the idea.
> For applications where the number exchange is performance critical,
> methinks it has legs.
> I am curious as to the Lua authors view of things?
> 
> DB

Thanks for the review.  One correction/clarification has been made to the wiki
concerning the semantics.  I think this patch does not complicate Lua's
semantics since CNUMBERs are just a restricted type of local:

"CNUMBERs can be thought of as locals at the top-most level. CNUMBERs override
globals, but they are overridden by locals. Since CNUMBERs are always top-level,
they never go out of scope, so no special handling is required to deal with
closures (as is true of other locals)."

I'm thinking more and more that this patch should be extended to all data types.
 So, replace "CNUMBER" with "C-local" in the above quote.  The set of functions
might then become

  int isclocal(lua_State * L, const char * varname, int * id_out);
  void getclocal(lua_State *L, int id, TValue * value_out);
  void setclocal(lua_State *L, int id, TValue * value);
  int lua_setclocalhandler(L, isclocal, getclocal, setclocal);

with just two additional opcodes:

  GETCLOCAL
  SETCLOCAL

That would eliminate needing to use one set of opcodes and function for every
data type (e.g. GETCBOOLEAN, GETCNUMBER, GETCSTRING, etc.).  The extension to
other data types hasn't been tested yet though, and I'm not entirely certain if
that would correctly handle types that use the "gc" field (e.g. string).