[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: Lua VM 'meta' questions
- From: "Aaron Brown" <arundelo@...>
- Date: Wed, 4 Oct 2006 14:27:12 -0400
Brett Kugler wrote:
While I have a pretty good idea what the answers would be,
I was hoping the community might be able to provide not
just the "no's", but possibly alternate solutions or ideas
for handling these requirements.
I have a "yes" and a "no". I offer some explanation but no
alternate solution for the "no".
* Can a LUA script call functions in another Lua
script,
Yes. Once a function exists, Lua doesn't care about where
it came from. It only needs to be accessible (as the value
of a global or local variable, a table field, the return
value of another function, etc.) to be called.
(Remember that functions are just a type of value. So the
question has the same answer as "can a Lua script manipulate
strings from another Lua script?")
i.e. will the VM automatically load the Lua script in
which the function is referenced?
Not automatically. You need to use a function like require
or loadfile to run the second script, at which point that
script can bring functions into existence.
* When compiling Lua scripts, will the compiler resolve
function calls to functions within other Lua scripts, i.e.
will the compiler ensure the function exists and that the
parameters are correct?
In Lua, this sort of thing is done at runtime (or, in the
case of parameters, not at all except for checking done by
the function itself). That's because, in the general case,
it's impossible to do at compile time. Figuring out cases
like:
FuncName = Str1 .. Str2 .. Str3
_G[FuncName]()
amounts to running the program.
It would be possible to write a lint-like tool that would
handle the specific case of global functions and global
table fields assigned to and called in the normal way. I'm
sure this has been done, but I don't know of anything.
Perhaps someone else can suggest something.
The strict.lua module (in the etc/ directory of the Lua
source distribution) catches typos in global variable names,
but it does this at runtime, so it doesn't help for global
functions (since calling nil is a runtime error anyway).
--
Aaron