if mm1 == mm2 then return mm1 else return nil end     end</pre><p>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><p><code>a ~= b</code> is equivalent to <code>not (a == b)</code>.</li><li><b>"lt":</b>the <code>&lt;</code> operation.<pre>     function lt_event (op1, op2)       if type(op1) == "number" and type(op2) == "number" then         return op1 &lt; op2   -- numeric comparison       elseif type(op1) == "string" and type(op2) == "string" then         return op1 &lt; op2   -- lexicographic comparison       else         local h = getcomphandler(op1, op2, "__lt")         if h then           return h(op1, op2)         else           error(&middot;&middot;&middot;);         end       end     end</pre><p><code>a &gt; b</code> is equivalent to <code>b &lt; a</code>.</li><li><b>"le":</b>the <code>&lt;=</code> operation.<pre>     function le_event (op1, op2)       if type(op1) == "number" and type(op2) == "number" then         return op1 &lt;= op2   -- numeric comparison       elseif type(op1) == "string" and type(op2) == "string" then         return op1 &lt;= op2   -- lexicographic comparison       else         local h = getcomphandler(op1, op2, "__le")         if h then           return h(op1, op2)         else           h = getcomphandler(op1, op2, "__lt")           if h then             return not h(op2, op1)           else             error(&middot;&middot;&middot;);           end         end       end     end</pre><p><code>a &gt;= b</code> is equivalent to <code>b &lt;= a</code>.Note that, in the absence of a "le" metamethod,Lua tries the "lt", assuming that <code>a &lt;= b</code> isequivalent to <code>not (b &lt; a)</code>.</li><li><b>"index":</b>The indexing access <code>table[key]</code>.<pre>     function gettable_event (table, key)       local h       if type(table) == "table" then         local v = rawget(table, key)         if v ~= nil then return v end         h = metatable(table).__index         if h == nil then return nil end       else         h = metatable(table).__index         if h == nil then           error(&middot;&middot;&middot;);         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</pre><p></li><li><b>"newindex":</b>The indexing assignment <code>table[key] = value</code>.<pre>     function settable_event (table, key, value)       local h       if type(table) == "table" then         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(&middot;&middot;&middot;);         end       end       if type(h) == "function" then         return h(table, key,value)    -- call the handler       else h[key] = value             -- or repeat operation on it       end     end</pre><p></li><li><b>"call":</b>called when Lua calls a value.<pre>     function function_event (func, ...)       if type(func) == "function" then         return func(...)   -- primitive call       else         local h = metatable(func).__call         if h then           return h(func, ...)         else           error(&middot;&middot;&middot;)         end       end     end</pre><p></li></ul><h2>2.9 - <a name="2.9">Environments</a></h2><p>Besides metatables,objects of types thread, function, and userdatahave another table associated with them,called their <em>environment</em>.Like metatables, environments are regular tables andmultiple objects can share the same environment.<p>Environments associated with userdata have no meaning for Lua.It is only a convenience feature for programmers to associate a table toa userdata.<p>Environments associated with threads are called<em>global environments</em>.They are used as the default environment for their threads andnon-nested functions created by the thread(through <a href="#pdf-loadfile"><code>loadfile</code></a>, <a href="#pdf-loadstring"><code>loadstring</code></a> or <a href="#pdf-load"><code>load</code></a>)and can be directly accessed by C&nbsp;code (see <a href="#3.3">&sect;3.3</a>).<p>Environments associated with C&nbsp;functions can be directlyaccessed by C&nbsp;code (see <a href="#3.3">&sect;3.3</a>).They are used as the default environment for other C&nbsp;functionscreated by the function.<p>Environments associated with Lua functions are used to resolveall accesses to global variables within the function (see <a href="#2.3">&sect;2.3</a>).They are used as the default environment for other Lua functionscreated by the function.<p>You can change the environment of a Lua function or therunning thread by calling <a href="#pdf-setfenv"><code>setfenv</code></a>.You can get the environment of a Lua function or the running threadby calling <a href="#pdf-getfenv"><code>getfenv</code></a>.To manipulate the environment of other objects(userdata, C&nbsp;functions, other threads) you mustuse the C&nbsp;API.<h2>2.10 - <a name="2.10">Garbage Collection</a></h2><p>Lua performs automatic memory management.This means thatyou have to worry neither about allocating memory for new objectsnor about freeing it when the objects are no longer needed.Lua manages memory automatically by runninga <em>garbage collector</em> from time to timeto collect all <em>dead objects</em>(that is, these objects that are no longer accessible from Lua).All objects in Lua are subject to automatic management:tables, userdata, functions, threads, and strings.<p>Lua implements an incremental mark-and-sweep collector.It uses two numbers to control its garbage-collection cycles:the <em>garbage-collector pause</em> andthe <em>garbage-collector step multiplier</em>.<p>The garbage-collector pausecontrols how long the collector waits before starting a new cycle.Larger values make the collector less aggressive.Values smaller than 1 mean the collector will not wait tostart a new cycle.A value of 2 means that the collector waits for the total memory in useto double before starting a new cycle.<p>The step multipliercontrols the relative speed of the collector relative tomemory allocation.Larger values make the collector more aggressive but also increasethe size of each incremental step.Values smaller than 1 make the collector too slow andmay result in  the collector never finishing a cycle.The default, 2, means that the collector runs at "twice"the speed of memory allocation.<p>You can change these numbers by calling <a href="#lua_gc"><code>lua_gc</code></a> in Cor <a href="#pdf-collectgarbage"><code>collectgarbage</code></a> in Lua.Both get percentage points as arguments(so an argument of 100 means a real value of 1).With these functions you can also control the collector directly (e.g., stop and restart it).<h3>2.10.1 - <a name="2.10.1">Garbage-Collection Metamethods</a></h3><p>Using the C&nbsp;API,you can set garbage-collector metamethods for userdata (see <a href="#2.8">&sect;2.8</a>).These metamethods are also called <em>finalizers</em>.Finalizers allow you to coordinate Lua's garbage collectionwith external resource management(such as closing files, network or database connections,or freeing your own memory).<p>Garbage userdata with a field <code>__gc</code> in their metatables are notcollected immediately by the garbage collector.Instead, Lua puts them in a list.After the collection,Lua does the equivalent of the following functionfor each userdata in that list:<pre>     function gc_event (udata)       local h = metatable(udata).__gc       if h then         h(udata)       end     end</pre><p>At the end of each garbage-collection cycle,the finalizers for userdata are called in <em>reverse</em>order of their creation,among those collected in that cycle.That is, the first finalizer to be called is the one associatedwith the userdata created last in the program.<h3>2.10.2 - <a name="2.10.2">Weak Tables</a></h3><p>A <em>weak table</em> is a table whose elements are<em>weak references</em>.A weak reference is ignored by the garbage collector.In other words,if the only references to an object are weak references,then the garbage collector will collect this object.<p>A weak table can have weak keys, weak values, or both.A table with weak keys allows the collection of its keys,but prevents the collection of its values.A table with both weak keys and weak values allows the collection ofboth keys and values.In any case, if either the key or the value is collected,the whole pair is removed from the table.The weakness of a table is controlled by the value of the<code>__mode</code> field of its metatable.If the <code>__mode</code> field is a string containing the character&nbsp;'<code>k</code>',the keys in the table are weak.If <code>__mode</code> contains '<code>v</code>',the values in the table are weak.<p>After you use a table as a metatable,you should not change the value of its field <code>__mode</code>.Otherwise, the weak behavior of the tables controlled by thismetatable is undefined.<h2>2.11 - <a name="2.11">Coroutines</a></h2><p>Lua supports coroutines,also called <em>collaborative multithreading</em>.A coroutine in Lua represents an independent thread of execution.Unlike threads in multithread systems, however,a coroutine only suspends its execution by explicitly callinga yield function.<p>You create a coroutine with a call to <a href="#pdf-coroutine.create"><code>coroutine.create</code></a>.Its sole argument is a functionthat is the main function of the coroutine.The <code>create</code> function only creates a new coroutine andreturns a handle to it (an object of type <em>thread</em>);it does not start the coroutine execution.<p>When you first call <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a>,passing as its first argumentthe thread returned by <a href="#pdf-coroutine.create"><code>coroutine.create</code></a>,the coroutine starts its execution,at the first line of its main function.Extra arguments passed to <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a> are passed onto the coroutine main function.After the coroutine starts running,it runs until it terminates or <em>yields</em>.<p>A coroutine can terminate its execution in two ways:normally, when its main function returns(explicitly or implicitly, after the last instruction);and abnormally, if there is an unprotected error.In the first case, <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a> returns <b>true</b>,plus any values returned by the coroutine main function.In case of errors, <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a> returns <b>false</b>plus an error message.<p>A coroutine yields by calling <a href="#pdf-coroutine.yield"><code>coroutine.yield</code></a>.When a coroutine yields,the corresponding <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a> returns immediately,even if the yield happens inside nested function calls(that is, not in the main function,but in a function directly or indirectly called by the main function).In the case of a yield, <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a> also returns <b>true</b>,plus any values passed to <a href="#pdf-coroutine.yield"><code>coroutine.yield</code></a>.The next time you resume the same coroutine,it continues its execution from the point where it yielded,with the call to <a href="#pdf-coroutine.yield"><code>coroutine.yield</code></a> returning any extraarguments passed to <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a>.<p>The <a href="#pdf-coroutine.wrap"><code>coroutine.wrap</code></a> function creates a coroutine,just like <a href="#pdf-coroutine.create"><code>coroutine.create</code></a>,but instead of returning the coroutine itself,it returns a function that, when called, resumes the coroutine.Any arguments passed to this functiongo as extra arguments to <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a>.<a href="#pdf-coroutine.wrap"><code>coroutine.wrap</code></a> returns all the values returned by <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a>,except the first one (the boolean error code).Unlike <a href="#pdf-coroutine.resume"><code>coroutine.resume</code></a>,<a href="#pdf-coroutine.wrap"><code>coroutine.wrap</code></a> does not catch errors;any error is propagated to the caller.<p>As an example,consider the following code:<pre>     function foo (a)       print("foo", a)       return coroutine.yield(2*a)     end          co = coroutine.create(function (a,b)           print("co-body", a, b)           local r = foo(a+1)           print("co-body", r)           local r, s = coroutine.yield(a+b, a-b)           print("co-body", r, s)           return b, "end"     end)                 print("main", coroutine.resume(co, 1, 10))     print("main",