lua-users home
lua-l archive

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


It was thus said that the Great Luyu Huang once stated:
> I mean Lua reserved words. In fact, my C module accepts strings from Lua 
> and I need to determine if they are reserved words; they are essentially 
> TString objects.

  All strings in Lua are TString objects (for PUC Lua; possibly not for
other Lua implementations like LuaJIT---keep that in mind), not just the
keywords used by the compiler portion.

>  So if I can get the TString object, I can determine it 
> directly, Instead of comparing them with a reserved words list, which is 
> costly. 

  My advice at this point would be to write code that works (scanning a list
of reserved words) and ensure the rest of the program is working correctly,
then profile and determine if in fact, the code that determines a Lua
keyword is, in fact, sucking up the runtime of the program.  In my
experience with profiling (just about any language) is that the hot spot is
almost never where you think it is.

  Here's an idea, create a Lua table like:

	keywords =
	{
	  ['and'] = true,
	  ['break'] = true,
	  ['do'] = true,
	  ['else'] = true,
	  -- and so on
	}

then do a table lookup:

	if keywords[word] then 
	  -- we have a keyword ...
	end

  This can be done in C, and by doing this, you'll be using Lua's underlying
hash table implementation, and hash tables tend to have O(1) (amortized)
access.

  But as I said, write the code first and prove it correct, then speed it
up.  At work, I had a Lua program run, in production, for nearly four years
before performance became an issue.

> I think it might be better for Lua to provide a function such as 
> `luaL_isreserved(lua_State *L, int idx)`.

  I would disagree as that is a very unique use case.

  -spc