manual.html

这是快速高效的脚本语言 LUA 的 win 移植到 ce 的版本. 这是 5.12的修改版

<pre>
	parlist1 ::= namelist [`<b>,</b>&acute; `<b>...</b>&acute;]  |  `<b>...</b>&acute;
</pre>
When a function is called,
the list of arguments is adjusted to
the length of the list of parameters,
unless the function is a variadic or <em>vararg function</em>,
which is
indicated by three dots (`<code>...</code>&acute;) at the end of its parameter list.
A vararg function does not adjust its argument list;
instead, it collects all extra arguments and supplies them
to the function through a <em>vararg expression</em>,
which is also written as three dots.
The value of this expression is a list of all actual extra arguments,
similar to a function with multiple results.
If a vararg expression is used inside another expression
or in the middle of a list of expressions,
then its return list is adjusted to one element.
If the expression is used as the last element of a list of expressions,
then no adjustment is made
(unless the call is enclosed in parentheses).

<p>As an example, consider the following definitions:
<pre>
       function f(a, b) end
       function g(a, b, ...) end
       function r() return 1,2,3 end
</pre>
Then, we have the following mapping from arguments to parameters and
to the vararg expression:
<pre>
       CALL            PARAMETERS

       f(3)             a=3, b=nil
       f(3, 4)          a=3, b=4
       f(3, 4, 5)       a=3, b=4
       f(r(), 10)       a=1, b=10
       f(r())           a=1, b=2

       g(3)             a=3, b=nil, ... -->  (nothing)
       g(3, 4)          a=3, b=4,   ... -->  (nothing)
       g(3, 4, 5, 8)    a=3, b=4,   ... -->  5  8
       g(5, r())        a=5, b=1,   ... -->  2  3
</pre>

<p>Results are returned using the <b>return</b> statement (see <a href="#control">2.4.4</a>).
If control reaches the end of a function
without encountering a <b>return</b> statement,
then the function returns with no results.

<p>The <em>colon</em> syntax
is used for defining <em>methods</em>,
that is, functions that have an implicit extra parameter <code>self</code>.
Thus, the statement
<pre>
       function t.a.b.c:f (...) ... end
</pre>
is syntactic sugar for
<pre>
       t.a.b.c.f = function (self, ...) ... end
</pre>

<p><a name="visibility"></a><a name="2.6"></a><h2>2.6 - Visibility Rules</h2>


<p>Lua is a lexically scoped language.
The scope of variables begins at the first statement <em>after</em>
their declaration and lasts until the end of the innermost block that
includes the declaration.
Consider the following example:
<pre>
       x = 10                -- global variable
       do                    -- new block
         local x = x         -- new `x', with value 10
         print(x)            --> 10
         x = x+1
         do                  -- another block
           local x = x+1     -- another `x'
           print(x)          --> 12
         end
         print(x)            --> 11
       end
       print(x)              --> 10  (the global one)
</pre>

<p>Notice that, in a declaration like <code>local x = x</code>,
the new <code>x</code> being declared is not in scope yet,
and so the second <code>x</code> refers to the outside variable.

<p>Because of the lexical scoping rules,
local variables can be freely accessed by functions
defined inside their scope.
A local variable used by an inner function is called
an <em>upvalue</em>, or <em>external local variable</em>,
inside the inner function.

<p>Notice that each execution of a <b>local</b> statement
defines new local variables.
Consider the following example:
<pre>
       a = {}
       local x = 20
       for i=1,10 do
         local y = 0
         a[i] = function () y=y+1; return x+y end
       end
</pre>
The loop creates ten closures
(that is, ten instances of the anonymous function).
Each of these closures uses a different <code>y</code> variable,
while all of them share the same <code>x</code>.

<p><a name="error"></a><a name="2.7"></a><h2>2.7 - Error Handling</h2>

<p>Because Lua is an embedded extension language,
all Lua actions start from C code in the host program
calling a function from the Lua library (see <a href="#lua_pcall"><code>lua_pcall</code></a>).
Whenever an error occurs during Lua compilation or execution,
control returns to C,
which can take appropriate measures
(such as printing an error message).

<p>Lua code can explicitly generate an error by calling the
<a href="#pdf-error"><code>error</code></a> function.
If you need to catch errors in Lua,
you can use the <a href="#pdf-pcall"><code>pcall</code></a> function.

<p><a name="metatable"></a><a name="2.8"></a><h2>2.8 - Metatables</h2>

<p>Every value in Lua may have a <em>metatable</em>.
This <em>metatable</em> is an ordinary Lua table
that defines the behavior of the original value
under certain special operations.
You can change several aspects of the behavior
of operations over a value by setting specific fields in its metatable.
For instance, when a non-numeric value is the operand of an addition,
Lua checks for a function in the field <code>"__add"</code> in its metatable.
If it finds one,
Lua calls this function to perform the addition.

<p>We call the keys in a metatable <em>events</em>
and the values <em>metamethods</em>.
In the previous example, the event is <code>"add"</code> 
and the metamethod is the function that performs the addition.

<p>You can query the metatable of any value
through the <a href="#pdf-getmetatable"><code>getmetatable</code></a> function.

<p>You can replace the metatable of tables
through the <a href="#pdf-setmetatable"><code>setmetatable</code></a>
function.
You cannot change the metatable of other types from Lua
(except using the debug library);
you must use the C API for that.

<p>Tables and userdata have individual metatables
(although multiple tables and userdata can share
a same table as their metatable);
values of all other types share one single metatable per type.
So, there is one single metatable for all numbers,
and for all strings, etc.

<p>A metatable may control how an object behaves in arithmetic operations,
order comparisons, concatenation, length operation, and indexing.
A metatable can also define a function to be called when a userdata
is garbage collected.
For each of these operations Lua associates a specific key
called an <em>event</em>.
When Lua performs one of these operations over a value,
it checks whether this value has a metatable with the corresponding event.
If so, the value associated with that key (the <em>metamethod</em>)
controls how Lua will perform the operation.

<p>Metatables control the operations listed next.
Each operation is identified by its corresponding name.
The key for each operation is a string with its name prefixed by
two underscores, `<code>__</code>&acute;;
for instance, the key for operation "add" is the
string <code>"__add"</code>.
The semantics of these operations is better explained by a Lua function
describing how the interpreter executes the operation.

<p>The code shown here in Lua is only illustrative;
the real behavior is hard coded in the interpreter
and it is much more efficient than this simulation.
All functions used in these descriptions
(<a href="#pdf-rawget"><code>rawget</code></a>, <a href="#pdf-tonumber"><code>tonumber</code></a>, etc.)
are described in <a href="#predefined">5.1</a>.
In particular, to retrieve the metamethod of a given object,
we use the expression
<pre>
       metatable(obj)[event]
</pre>
This should be read as
<pre>
       rawget(getmetatable(obj) or {}, event)
</pre>
That is, the access to a metamethod does not invoke other metamethods,
and the access to objects with no metatables does not fail
(it simply results in <b>nil</b>).

<p><ul>
<li><b>"add":</b>
the <code>+</code> operation.

<p>The function <code>getbinhandler</code> below defines how Lua chooses a handler
for a binary operation.
First, Lua tries the first operand.
If its type does not define a handler for the operation,
then Lua tries the second operand.
<pre>
 function getbinhandler (op1, op2, event)
   return metatable(op1)[event] or metatable(op2)[event]
 end
</pre>
Using this function,
the behavior of the <code>op1 + op2</code> is
<pre>
 function add_event (op1, op2)
   local o1, o2 = tonumber(op1), tonumber(op2)
   if o1 and o2 then  -- both operands are numeric?
     return o1 + o2   -- `+' here is the primitive `add'
   else  -- at least one of the operands is not numeric
     local h = getbinhandler(op1, op2, "__add")
     if h then
       -- call the handler with both operands
       return h(op1, op2)
     else  -- no handler available: default behavior
       error("...")
     end
   end
 end
</pre>

<p><li><b>"sub":</b>
the <code>-</code> operation.
Behavior similar to the "add" operation.

<p><li><b>"mul":</b>
the <code>*</code> operation.
Behavior similar to the "add" operation.

<p><li><b>"div":</b>
the <code>/</code> operation.
Behavior similar to the "add" operation.

<p><li><b>"mod":</b>
the <code>%</code> operation.
Behavior similar to the "add" operation,
with the operation
<code>o1 - floor(o1/o2)*o2</code> as the primitive operation.

<p><li><b>"pow":</b>
the <code>^</code> (exponentiation) operation.
Behavior similar to the "add" operation,
with the function <code>pow</code> (from the C math library)
as the primitive operation.

<p><li><b>"unm":</b>
the unary <code>-</code> operation.
<pre>
 function unm_event (op)
   local o = tonumber(op)
   if o then  -- operand is numeric?
     return -o  -- `-' here is the primitive `unm'
   else  -- the operand is not numeric.
     -- Try to get a handler from the operand
     local h = metatable(op).__unm
     if h then
       -- call the handler with the operand
       return h(op)
     else  -- no handler available: default behavior
       error("...")
     end
   end
 end
</pre>

<p><li><b>"concat":</b>
the <code>..</code> (concatenation) operation.
<pre>
 function concat_event (op1, op2)
   if (type(op1) == "string" or type(op1) == "number") and
      (type(op2) == "string" or type(op2) == "number") then
     return op1 .. op2  -- primitive string concatenation
   else
     local h = getbinhandler(op1, op2, "__concat")
     if h then
       return h(op1, op2)
     else
       error("...")
     end
   end
 end
</pre>

<p><li><b>"len":</b>
the <code>#</code> operation.
<pre>
 function len_event (op)
   if type(op) == "string" then
     return strlen(op)         -- primitive string length
   elseif type(op) == "table" then
     return #op                -- primitive table length
   else
     local h = metatable(op).__len
     if h then
       -- call the handler with the operand
       return h(op)
     else  -- no handler available: default behavior
       error("...")
     end
   end
 end
</pre>
See <a href="#len-op">2.5.5</a> for a description of the length of a table.

<p><li><b>"eq":</b>
the <code>==</code> operation.
The function <code>getcomphandler</code> defines how Lua chooses a metamethod
for comparison operators.
A metamethod only is selected when both objects
being compared have the same type
and the same metamethod for the selected operation.
<pre>
 function getcomphandler (op1, op2, event)
   if type(op1) ~= type(op2) then return nil end
   local mm1 = metatable(op1)[event]
   local mm2 = metatable(op2)[event]
   if mm1 == mm2 then return mm1 else return nil end
 end
</pre>
The "eq" event is defined as follows:
<pre>
 function eq_event (op1, op2)
   if type(op1) ~= type(op2) then  -- different types?
     return false   -- different objects
   end
   if op1 == op2 then   -- primitive equal?
     return true   -- objects are equal
   end
   -- try metamethod
   local h = getcomphandler(op1, op2, "__eq")
   if h then
     return h(op1, op2)
   else
     return false
   end
 end
</pre>
<code>a ~= b</code> is equivalent to <code>not (a == b)</code>.

<p><li><b>"lt":</b>
the <code>&#060;</code> operation.