(find-shttpfile "www.lua.org/ftp/") (find-es "lua" "lua5.0-beta") (find-es "lua5" "lua50betaref.e") (code-ps "lua50" "$S/http/www.lua.org/ftp/refman-5.0-beta.ps.gz") (find-lua50page 1) The Lua Programming Language Reference Manual for Lua version 5.0 (beta) Last revised on December 17, 2002 Lua Copyright (c) 2002 Tecgraf, PUC-Rio. All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the ''Software''), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED ''AS IS'', WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. Copies of this manual can be obtained at Lua's official web site, www.lua.org. The Lua logo was designed by A. Nakonechny. Copyright (c) 1998. All rights reserved. Reference Manual of the Programming Language Lua 5.0 (beta) Roberto Ierusalimschy Luiz Henrique de Figueiredo Waldemar Celes lua@tecgraf.puc-rio.br Tecgraf --- Computer Science Department --- PUC-Rio December 17, 2002 Abstract Lua is a powerful, light-weight programming language designed for extending applications. Lua is also frequently used as a general-purpose, stand-alone language. Lua combines simple procedural syntax (similar to Pascal) with powerful data description constructs based on associative arrays and extensible semantics. Lua is dynamically typed, interpreted from opcodes, and has automatic memory management with garbage collection, making it ideal for configuration, scripting, and rapid prototyping. This document describes version 5.0 (beta) of the Lua programming language and the application Program Interface (API) that allows interaction between Lua programs and their host C programs. Resumo Lua é uma linguagem de programação poderosa e leve, projetada para estender aplicações. Lua também é frequentemente usada como uma linguagem de propósito geral. Lua combina programação procedural (com sintaxe semelhante à de Pascal) com poderosas construções para descrição de dados, baseadas em tabelas associativas e semântica extensível. Lua é tipada dinamicamente, interpretada a partir de opcodes, e tem gerenciamento automático de memória com coleta de lixo. Essas características fazem de Lua uma linguagem ideal para configuração, automação (scripting) e prototipagem rápida. Este documento descreve a versão 5.0 (beta) da linguagem de programação Lua e a Interface de Programação (API) que permite a interação entre programas Lua e programas C hospedeiros. i ii Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . 1 (to "sec1") 2 Lua Concepts . . . . . . . . . . . . . . . . . . . . . . 1 (to "sec2") 2.1 Environment and Chunks . . . . . . . . . . . . . . . . 1 (to "sec2.1") 2.2 Table of Globals . . . . . . . . . . . . . . . . . . . 2 (to "sec2.2") 2.3 Values and Types . . . . . . . . . . . . . . . . . . . 2 (to "sec2.3") 2.3.1 Metatables . . . . . . . . . . . . . . . . . . . . . 3 (to "sec2.3.1") 2.4 Coercion . . . . . . . . . . . . . . . . . . . . . . . 3 (to "sec2.4") 2.5 Variables . . . . . . . . . . . . . . . . . . . . . . . 3 (to "sec2.5") 2.6 Garbage Collection . . . . . . . . . . . . . . . . . . 3 (to "sec2.6") 2.6.1 Weak Tables . . . . . . . . . . . . . . . . . . . . . 4 (to "sec2.6.1") 3 The Language . . . . . . . . . . . . . . . . . . . . . . 4 (to "sec3") 3.1 Lexical Conventions . . . . . . . . . . . . . . . . . . 4 (to "sec3.1") 3.2 Variables . . . . . . . . . . . . . . . . . . . . . . . 5 (to "sec3.2") 3.3 Statements . . . . . . . . . . . . . . . . . . . . . . 6 (to "sec3.3") 3.3.1 Chunks . . . . . . . . . . . . . . . . . . . . . . . 6 (to "sec3.3.1") 3.3.2 Blocks . . . . . . . . . . . . . . . . . . . . . . . 6 (to "sec3.3.2") 3.3.3 Assignment . . . . . . . . . . . . . . . . . . . . . 6 (to "sec3.3.3") 3.3.4 Control Structures . . . . . . . . . . . . . . . . . 7 (to "sec3.3.4") 3.3.5 For Statement . . . . . . . . . . . . . . . . . . . . 7 (to "sec3.3.5") 3.3.6 Function Calls as Statements . . . . . . . . . . . . 9 (to "sec3.3.6") 3.3.7 Local Declarations . . . . . . . . . . . . . . . . . 9 (to "sec3.3.7") 3.4 Expressions . . . . . . . . . . . . . . . . . . . . . . 9 (to "sec3.4") 3.4.1 Arithmetic Operators . . . . . . . . . . . . . . . . 9 (to "sec3.4.1") 3.4.2 Relational Operators . . . . . . . . . . . . . . . . 10 (to "sec3.4.2") 3.4.3 Logical Operators . . . . . . . . . . . . . . . . . . 10 (to "sec3.4.3") 3.4.4 Concatenation . . . . . . . . . . . . . . . . . . . . 10 (to "sec3.4.4") 3.4.5 Precedence . . . . . . . . . . . . . . . . . . . . . 11 (to "sec3.4.5") 3.4.6 Table Constructors . . . . . . . . . . . . . . . . . 11 (to "sec3.4.6") 3.4.7 Function Calls . . . . . . . . . . . . . . . . . . . 12 (to "sec3.4.7") 3.4.8 Function Definitions . . . . . . . . . . . . . . . . 13 (to "sec3.4.8") 3.5 Visibility Rules . . . . . . . . . . . . . . . . . . . 14 (to "sec3.5") 3.6 Error Handling . . . . . . . . . . . . . . . . . . . . 15 (to "sec3.6") 3.7 Metatables . . . . . . . . . . . . . . . . . . . . . . 15 (to "sec3.7") 3.7.1 Metatables and Garbage collection . . . . . . . . . . 19 (to "sec3.7.1") 3.8 Coroutines . . . . . . . . . . . . . . . . . . . . . . 20 (to "sec3.8") 4 The Application Program Interface . . . . . . . . . . . . 21 (to "sec4") 4.1 States . . . . . . . . . . . . . . . . . . . . . . . . 21 (to "sec4.1") 4.2 Threads . . . . . . . . . . . . . . . . . . . . . . . . 21 (to "sec4.2") 4.3 The Stack and Indices . . . . . . . . . . . . . . . . . 22 (to "sec4.3") 4.4 Stack Manipulation . . . . . . . . . . . . . . . . . . 23 (to "sec4.4") 4.5 Querying the Stack . . . . . . . . . . . . . . . . . . 23 (to "sec4.5") 4.6 Getting Values from the Stack . . . . . . . . . . . . . 24 (to "sec4.6") 4.7 Pushing Values onto the Stack . . . . . . . . . . . . . 25 (to "sec4.7") iii 4.8 Controlling Garbage Collection . . . . . . . . . . . . 26 (to "sec4.8") 4.9 Userdata . . . . . . . . . . . . . . . . . . . . . . . 26 (to "sec4.9") 4.10 Metatables . . . . . . . . . . . . . . . . . . . . . . 27 (to "sec4.10") 4.11 Loading Lua Chunks . . . . . . . . . . . . . . . . . . 27 (to "sec4.11") 4.12 Manipulating Tables . . . . . . . . . . . . . . . . . 27 (to "sec4.12") 4.13 Manipulating Global Variables . . . . . . . . . . . . 29 (to "sec4.13") 4.14 Using Tables as Arrays . . . . . . . . . . . . . . . . 29 (to "sec4.14") 4.15 Calling Functions . . . . . . . . . . . . . . . . . . 29 (to "sec4.15") 4.16 Protected Calls . . . . . . . . . . . . . . . . . . . 30 (to "sec4.16") 4.17 Defining C Functions . . . . . . . . . . . . . . . . . 31 (to "sec4.17") 4.18 Defining C Closures . . . . . . . . . . . . . . . . . 32 (to "sec4.18") 5 The Debug Interface . . . . . . . . . . . . . . . . . . . 32 (to "sec5") 5.1 Stack and Function Information . . . . . . . . . . . . 32 (to "sec5.1") 5.2 Manipulating Local Variables . . . . . . . . . . . . . 34 (to "sec5.2") 5.3 Hooks . . . . . . . . . . . . . . . . . . . . . . . . . 34 (to "sec5.3") 6 Standard Libraries . . . . . . . . . . . . . . . . . . . 35 (to "sec6") 6.1 Basic Functions . . . . . . . . . . . . . . . . . . . . 36 (to "sec6.1") 6.2 String Manipulation . . . . . . . . . . . . . . . . . . 39 (to "sec6.2") 6.3 Table Manipulation . . . . . . . . . . . . . . . . . . 44 (to "sec6.3") 6.4 Mathematical Functions . . . . . . . . . . . . . . . . 45 (to "sec6.4") 6.5 Input and Output Facilities . . . . . . . . . . . . . . 46 (to "sec6.5") 6.6 Operating System Facilities . . . . . . . . . . . . . . 49 (to "sec6.6") 6.7 The Reflexive Debug Interface . . . . . . . . . . . . . 50 (to "sec6.7") 7 Lua Stand-alone . . . . . . . . . . . . . . . . . . . . . 52 (to "sec7") Incompatibilities with Previous Versions . . . . . . . . . . . . . . . . . 53 The Complete Syntax of Lua . . . . . . . . . . . . . . . . . . . . . . . . 55 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 iv # «sec1» # «Introduction» 1 Introduction Lua is an extension programming language designed to support general procedural programming with data description facilities. Lua is intended to be used as a powerful, light-weight configuration language for any program that needs one. Lua is implemented as a library, written in C. Being an extension language, Lua has no notion of a ``main'' program: it only works embedded in a host client, called the embedding program or simply the host. This host program can invoke functions to execute a piece of Lua code, can write and read Lua variables, and can register C functions to be called by Lua code. Through the use of C functions, Lua can be augmented to cope with a wide range of different domains, thus creating customized programming languages sharing a syntactical framework. Lua is free software, and is provided as usual with no guarantees, as stated in its copyright notice. The implementation described in this manual is available at Lua's official web site, www.lua.org. Like any other reference manual, this document is dry in places. For a discussion of the decisions behind the design of Lua, see the papers below, which are available at Lua's web site. . R. Ierusalimschy, L. H. de Figueiredo, and W. Celes. Lua---an extensible extension language. Software: Practice & Experience 26 #6 (1996) 635--652. . L. H. de Figueiredo, R. Ierusalimschy, and W. Celes. The design and implementation of a language for extending applications. Proceedings of XXI Brazilian Seminar on Software and Hardware (1994) 273--283. . L. H. de Figueiredo, R. Ierusalimschy, and W. Celes. Lua: an extensible embedded language. Dr. Dobb's Journal 21 #12 (Dec 1996) 26--33. . R. Ierusalimschy, L. H. de Figueiredo, and W. Celes. The evolution of an extension language: a history of Lua, Proceedings of V Brazilian Symposium on Programming Languages (2001) B-14--B-28. Lua means ``moon'' in Portuguese. # «sec2» # «Lua Concepts» 2 Lua Concepts This section describes the main concepts of Lua as a language. The syntax and semantics of Lua are described in (to "sec3"). The discussion below is not purely conceptual; it includes references to the C API (see (to "sec4")), because Lua is designed to be embedded in host programs. It also includes references to the standard libraries (see (to "sec6")). # «sec2.1» # «Environment and Chunks» 2.1 Environment and Chunks All statements in Lua are executed in a global environment . This environment is initialized with a call from the embedding program to lua_open and persists until a call to lua_close or the end of the embedding program. The host program can create multiple independent global environments, and freely switch between them (see (to "sec4.1")). The unit of execution of Lua is called a chunk . A chunk is simply a sequence of statements. Statements are described in (to "sec3.3"). A chunk may be stored in a file or in a string inside the host program. When a chunk is executed, first it is pre-compiled into opcodes for a virtual machine, and then the compiled statements are # «p1» (find-lua50page 1) executed by an interpreter for the virtual machine. All modifications a chunk makes to the global environment persist after the chunk ends. Chunks may also be pre-compiled into binary form and stored in files; see program luac for details. Programs in source and compiled forms are interchangeable; Lua automatically detects the file type and acts accordingly. # «sec2.2» # «Table of Globals» 2.2 Table of Globals ???? # «sec2.3» # «Values and Types» 2.3 Values and Types Lua is a dynamically typed language. That means that variables do not have types; only values do. There are no type definitions in the language. All values carry their own type. There are eight basic types in Lua: nil , boolean, number , string , function, userdata, thread , and table. Nil is the type of the value nil, whose main property is to be different from any other value; usually it represents the absence of a useful value. Boolean is the type of the values false and true. In Lua, both nil and false make a condition false, and any other value makes it true. Number represents real (double-precision floating-point) numbers. String represents arrays of characters. Lua is 8-bit clean, and so strings may contain any 8-bit character, including embedded zeros ('\0') (see (to "sec3.1")). Functions are first-class values in Lua. That means that functions can be stored in variables, passed as arguments to other functions, and returned as results. Lua can call (and manipulate) functions written in Lua and functions written in C (see (to "sec3.4.7")). The type userdata is provided to allow arbitrary C data to be stored in Lua variables. This type corresponds to a block of raw memory and has no pre-defined operations in Lua, except assignment and identity test. However, by using metatables, the programmer can define operations for userdata values (see (to "sec3.7")). Userdata values cannot be created or modified in Lua, only through the C API. This guarantees the integrity of data owned by the host program. The type thread represents independent threads of execution, and it is used to implement coroutines. (This is an experimental area; it needs more documentation, and is subject to changes in the future.) The type table implements associative arrays, that is, arrays that can be indexed not only with numbers, but with any value (except nil). Moreover, tables can be heterogeneous, that is, they can contain values of all types. Tables are the sole data structuring mechanism in Lua; they may be used not only to represent ordinary arrays, but also symbol tables, sets, records, graphs, trees, etc. To represent records, Lua uses the field name as an index. The language supports this representation by providing a.name as syntactic sugar for a["name"]. There are several convenient ways to create tables in Lua (see (to "sec3.4.6")). Like indices, the value of a table field can be of any type. In particular, because functions are first class values, table fields may contain functions. So, tables may also carry methods (see (to "sec3.4.8")). Tables, functions, and userdata values are objects: variables do not actually contain these values, only references to them. Assignment, parameter passing, and function returns always manipulate references to these values, and do not imply any kind of copy. The library function type returns a string describing the type of a given value (see (to "sec6.1")). # «p2» (find-lua50page 2) # «sec2.3.1» # «Metatables» 2.3.1 Metatables Each table and userdata object in Lua may have a metatable. You can change several aspects of the behavior of an object by setting specific fields in its metatable. For instance, when an object is the operand of an addition, Lua checks for a function in the field "__add" in its metatable. If it finds one, Lua calls that function to perform the addition. We call the keys in a metatable events, and the values metamethods. In the previous example, "add" is the event, and the function is the metamethod that performs the addition. A metatable controls how an object behaves in arithmetic operations, order comparisons, concatenation, and indexing. A metatable can also define a function to be called when a userdata is garbage collected. (to "sec3.7") gives a detailed description of which events you can control with metatables. You can query and change the metatable of an object through the setmetatable and getmetatable functions (see (to "sec6.1")). # «sec2.4» # «Coercion» 2.4 Coercion Lua provides automatic conversion between string and number values at run time. Any arithmetic operation applied to a string tries to convert that string to a number, following the usual rules. Conversely, whenever a number is used when a string is expected, the number is converted to a string, in a reasonable format. The format is chosen so that a conversion from number to string then back to number reproduces the original number exactly. For complete control of how numbers are converted to strings, use the format function (see (to "sec6.2")). # «sec2.5» # «Variables» 2.5 Variables There are two kinds of variables in Lua: global variables and local variables. Variables are assumed to be global unless explicitly declared local (see (to "sec3.3.7")). Before the first assignment, the value of a variable is nil. All global variables live as fields in ordinary Lua tables. Usually, globals live in a table called table of globals. However, a function can individually change its global table, so that all global variables in that function will refer to that table. This mechanism allows the creation of namespaces and other modularization facilities. Local variables are lexically scoped. Therefore, local variables can be freely accessed by functions defined inside their scope (see (to "sec3.5")). # «sec2.6» # «Garbage Collection» 2.6 Garbage Collection Lua does automatic memory management. That means that you do not have to worry about allocating memory for new objects and freeing it when the objects are no longer needed. Lua manages memory automatically by running a garbage collector from time to time and collecting all dead objects (all objects that are no longer accessible from Lua). All objects in Lua are subject to automatic management: tables, userdata, functions, and strings. Using the C API, you can set garbage-collector metamethods for userdata (see (to "sec3.7")). When it is about to free a userdata, Lua calls the metamethod associated with event gc in the userdata's metatable. Using such facility, you can coordinate Lua's garbage collection with external resource management (such as closing files, network or database connections, or freeing your own memory). Lua uses two numbers to control its garbage-collection cycles. One number counts how many bytes of dynamic memory Lua is using, and the other is a threshold. When the number of bytes # «p3» (find-lua50page 3) crosses the threshold, Lua runs the garbage collector, which reclaims the memory of all dead objects. The byte counter is corrected, and then the threshold is reset to twice the value of the byte counter. Through the C API, you can query those numbers, and change the threshold (see (to "sec4.8")). Setting the threshold to zero actually forces an immediate garbage-collection cycle, while setting it to a huge number effectively stops the garbage collector. Using Lua code you have a more limited control over garbage-collection cycles, through the functions gcinfo and collectgarbage (see (to "sec6.1")). # «sec2.6.1» # «Weak Tables» 2.6.1 Weak Tables A weak table is a table whose elements are weak references. 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 that object. 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 of both 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 controled by the value of the __mode field of its metatable. If the __mode field is a string containing the k character, the keys in the table are weak. If __mode contains v, the values in the table are weak. # «sec3» # «The Language» 3 The Language This section describes the lexis, the syntax, and the semantics of Lua. In other words, this section describes which tokens are valid, how they can be combined, and what their combinations mean. # «sec3.1» # «Lexical Conventions» 3.1 Lexical Conventions Identifiers in Lua can be any string of letters, digits, and underscores, not beginning with a digit. This coincides with the definition of identifiers in most languages. (The definition of letter depends on the current locale: any character considered alphabetic by the current locale can be used in an identifier.) The following keywords are reserved, and cannot be used as identifiers: and break do else elseif end false for function if in local nil not or repeat return then true until while Lua is a case-sensitive language: and is a reserved word, but And and ánd (if the locale permits) are two different, valid identifiers. As a convention, identifiers starting with an underscore followed by uppercase letters (such as _VERSION) are reserved for internal variables. The following strings denote other tokens: + - * / ^ = ~= <= >= < > == ( ) { } [ ] ; : , . .. ... # «p4» (find-lua50page 4) Literal strings can be delimited by matching single or double quotes, and can contain the C-like escape sequences `\a' (bell), `\b' (backspace), `\f' (form feed), `\n' (newline), `\r' (carriage return), `\t' (horizontal tab), `\v' (vertical tab), `\\' (backslash), `\"' (double quote), `\'' (single quote), and `\newline' (that is, a backslash followed by a real newline, which results in a newline in the string). A character in a string may also be specified by its numerical value, through the escape sequence `\ddd ', where ddd is a sequence of up to three decimal digits. Strings in Lua may contain any 8-bit value, including embedded zeros, which can be specified as `\0'. Literal strings can also be delimited by matching [[ . . . ]]. Literals in this bracketed form may run for several lines, may contain nested [[ . . . ]] pairs, and do not interpret escape sequences. For convenience, when the opening [[ is immediately followed by a newline, the newline is not included in the string. That form is specially convenient for writing strings that contain program pieces or other quoted strings. As an example, in a system using ASCII (in which `a' is coded as 97, newline is coded as 10, and `1' is coded as 49), the four literals below denote the same string: (1) "alo\n123\"" (2) '\97lo\10\04923"' (3) [[alo 123"]] (4) [[ alo 123"]] Numerical constants may be written with an optional decimal part and an optional decimal exponent. Examples of valid numerical constants are 3 3.0 3.1416 314.16e-2 0.31416E1 Comments start anywhere outside a string with a double hyphen (--); If the text after -- is different from [[, the comment is a short comment, that runs until the end of the line. Otherwise, it is a long comment, that runs until the corresponding ]]. Long comments may run for several lines, and may contain nested [[ . . . ]] pairs. For convenience, the first line of a chunk is skipped if it starts with #. This facility allows the use of Lua as a script interpreter in Unix systems (see (to "sec7")). # «sec3.2» # «Variables» 3.2 Variables Variables are places that store values. A single name can denote a global variable, a local variable, or a formal parameter in a function (formal parameters are just local variables): var -> Name Square brackets are used to index a table: var -> prefixexp `[' exp `]' The first expression should result in a table value, and the second expression identifies a specific entry inside that table. The syntax var.NAME is just syntactic sugar for var["NAME"]: var -> prefixexp `.' Name The expression denoting the table to be indexed has a restricted syntax; (to "sec3.4") for details. The meaning of assignments and evaluations of global and indexed variables can be changed via metatables. An assignment to a global variable x = val is equivalent to the assignment # «p5» (find-lua50page 5) _glob.x = val, where _glob is the table of globals of the running function ((see (to "sec2.2")) for a discussion about the table of globals). An assignment to an indexed variable t[i] = val is equivalent to settable_event(t,i,val). An access to a global variable x is equivalent to _glob.x (again, (see (to "sec2.2")) for a discussion about _glob). An access to an indexed variable t[i] is equivalent to a call gettable_event(t,i). See (to "sec3.7") for a complete description of the settable_event and gettable_event functions. (These functions are not defined in Lua. We use them here only for explanatory purposes.) # «sec3.3» # «Statements» 3.3 Statements Lua supports an almost conventional set of statements, similar to those in Pascal or C. The conventional commands include assignment, control structures, and procedure calls. Non-conventional commands include table constructors and variable declarations. # «sec3.3.1» # «Chunks» 3.3.1 Chunks The unit of execution of Lua is called a chunk . A chunk is simply a sequence of statements, which are executed sequentially. Each statement can be optionally followed by a semicolon: chunk -> { stat [ `;' ] } # «sec3.3.2» # «Blocks» 3.3.2 Blocks A block is a list of statements; syntactically, a block is equal to a chunk: block -> chunk A block may be explicitly delimited to produce a single statement: stat -> do block end Explicit blocks are useful to control the scope of variable declarations. Explicit blocks are also sometimes used to add a return or break statement in the middle of another block (see (to "sec3.3.4")). # «sec3.3.3» # «Assignment» 3.3.3 Assignment Lua allows multiple assignment. Therefore, the syntax for assignment defines a list of variables on the left side and a list of expressions on the right side. The elements in both lists are separated by commas: stat -> varlist1 `=' explist1 varlist1 -> var { `,' var } explist1 -> exp { `,' exp } Expressions are discussed in (to "sec3.4"). Before the assignment, the list of values is adjusted to the length of the list of variables. If there are more values than needed, the excess values are thrown away. If there are less values than needed, the list is extended with as many nil's as needed. If the list of expressions ends with a function call, then all values returned by that function call enter in the list of values, before the adjust (except when the call is enclosed in parentheses; see (to "sec3.4")). The assignment statement first evaluates all its expressions, and only then makes the assignments. So, the code # «p6» (find-lua50page 6) i = 3 i, a[i] = i+1, 20 sets a[3] to 20, without affecting a[4] because the i in a[i] is evaluated before it is assigned 4. Similarly, the line x, y = y, x exchanges the values of x and y. # «sec3.3.4» # «Control Structures» 3.3.4 Control Structures The control structures if, while, and repeat have the usual meaning and familiar syntax: stat -> while exp do block end stat -> repeat block until exp stat -> if exp then block { elseif exp then block } [ else block ] end Lua also has a for statement, in two flavors (see (to "sec3.3.5")). The condition expression exp of a control structure may return any value. All values different from nil and false are considered true (in particular, the number 0 and the empty string are also true); both false and nil are considered false. The return statement is used to return values from a function or from a chunk. Functions and chunks may return more than one value, and so the syntax for the return statement is stat -> return [ explist1 ] The break statement can be used to terminate the execution of a while, repeat, or for loop, skipping to the next statement after the loop: stat -> break A break ends the innermost enclosing loop. NOTE : For syntactic reasons, return and break statements can only be written as the last statement of a block. If it is really necessary to return or break in the middle of a block, then an explicit inner block can used, as in the idioms `do return end' and `do break end', because now return and break are the last statements in their (inner) blocks. In practice, those idioms are only used during debugging. (For instance, a line `do return end' can be added at the beginning of a chunk for syntax checking only.) # «sec3.3.5» # «For Statement» 3.3.5 For Statement The for statement has two forms, one for numbers and one generic. The numerical for loop repeats a block of code while a control variable runs through an arithmetic progression. It has the following syntax: stat -> for Name `=' exp `,' exp [ `,' exp ] do block end The block is repeated for name starting at the value of the first exp, until it reaches the second exp by steps of the third exp. More precisely, a for statement like for var = e1, e2, e3 do block end is equivalent to the code: # «p7» (find-lua50page 7) do local var, _limit, _step = tonumber(e1), tonumber(e2), tonumber(e3) if not (var and _limit and _step) then error() end while (_step>0 and var<=_limit) or (_step<=0 and var>=_limit) do block var = var+_step end end Note the following: . Both the limit and the step are evaluated only once, before the loop starts. . _limit and _step are invisible variables. The names are here for explanatory purposes only. . The behavior is undefined if you assign to var inside the block. . If the third expression (the step) is absent, then a step of 1 is used. . You can use break to exit a for loop. . The loop variable var is local to the statement; you cannot use its value after the for ends or is broken. If you need the value of the loop variable var, then assign it to another variable before breaking or exiting the loop. The generic for statement works over functions, called generators. It calls its generator to produce a new value for each iteration, stopping when the new value is nil. It has the following syntax: stat -> for Name { `,' Name } in explist1 do block end A for statement like for var_1, ..., var_n in explist do block end is equivalent to the code: do local _f, _s, var_1, ..., var_n = explist while 1 do var_1, ..., var_n = _f(_s, var_1) if var_1 == nil then break end block end end Note the following: . explist is evaluated only once. Its results are a ``generator'' function, a ``state'', and an initial value for the ``iterator variable''. . _f and _s are invisible variables. The names are here for explanatory purposes only. . The behavior is undefined if you assign to any var_i inside the block. . You can use break to exit a for loop. . The loop variables var_i are local to the statement; you cannot use their values after the for ends. If you need these values, then assign them to other variables before breaking or exiting the loop. # «p8» (find-lua50page 8) # «sec3.3.6» # «Function Calls as Statements» 3.3.6 Function Calls as Statements Because of possible side-effects, function calls can be executed as statements: stat -> functioncall In this case, all returned values are thrown away. Function calls are explained in (to "sec3.4.7"). # «sec3.3.7» # «Local Declarations» 3.3.7 Local Declarations Local variables may be declared anywhere inside a block. The declaration may include an initial assignment: stat -> local namelist [ `=' explist1 ] namelist -> Name { `,' Name } If present, an initial assignment has the same semantics of a multiple assignment (see (to "sec3.3.3")). Otherwise, all variables are initialized with nil. A chunk is also a block (see (to "sec3.3.1")), and so local variables can be declared outside any explicit block. Such local variables die when the chunk ends. Visibility rules for local variables are explained in (to "sec3.5"). # «sec3.4» # «Expressions» 3.4 Expressions The basic expressions in Lua are the following: exp -> prefixexp exp -> nil | false | true exp -> Number exp -> Literal exp -> function exp -> tableconstructor prefixexp -> var | functioncall | `(' exp `)' An expression enclosed in parentheses always results in only one value. Thus, (f(x,y,z)) is always a single value, even if f returns several values. (The value of (f(x,y,z)) is the first value returned by f or nil if f does not return any values.) Numbers and literal strings are explained in (to "sec3.1"); variables are explained in (to "sec3.2"); function definitions are explained in (to "sec3.4.8"); function calls are explained in (to "sec3.4.7"); table constructors are explained in (to "sec3.4.6"). Expressions can also be built with arithmetic operators, relational operators, and logical operadors, all of which are explained below. # «sec3.4.1» # «Arithmetic Operators» 3.4.1 Arithmetic Operators Lua supports the usual arithmetic operators: the binary + (addition), - (subtraction), * (multiplication), / (division), and ^ (exponentiation); and unary - (negation). If the operands are numbers, or strings that can be converted to numbers (see (to "sec2.4")), then all operations except exponentiation have the usual meaning, while exponentiation calls a global function pow; ?? otherwise, an appropriate metamethod is called (see (to "sec3.7")). The standard mathematical library defines function pow, giving the expected meaning to exponentiation (see (to "sec6.4")). # «p9» (find-lua50page 9) # «sec3.4.2» # «Relational Operators» 3.4.2 Relational Operators The relational operators in Lua are == ~= < > <= >= These operators always result in false or true. Equality (==) first compares the type of its operands. If the types are different, then the result is false. Otherwise, the values of the operands are compared. Numbers and strings are compared in the usual way. Tables, userdata, and functions are compared by reference, that is, two tables are considered equal only if they are the same table. Every time you create a new table (or userdata, or function), this new value is different from any previously existing value. NOTE : The conversion rules of (to "sec2.4") do not apply to equality comparisons. Thus, "0"==0 evaluates to false, and t[0] and t["0"] denote different entries in a table. The operator ~= is exactly the negation of equality (==). The order operators work as follows. If both arguments are numbers, then they are compared as such. Otherwise, if both arguments are strings, then their values are compared according to the current locale. Otherwise, the ``lt'' or the ``le'' metamethod is called (see (to "sec3.7")). # «sec3.4.3» # «Logical Operators» 3.4.3 Logical Operators The logical operators in Lua are and or not Like the control structures (see (to "sec3.3.4")), all logical operators consider both false and nil as false and anything else as true. The operator not always return false or true. The conjunction operator and returns its first argument if its value is false or nil; otherwise, and returns its second argument. The disjunction operator or returns its first argument if it is different from niland false; otherwise, or returns its second argument. Both and and or use short-cut evaluation, that is, the second operand is evaluated only if necessary. For example, 10 or error() -> 10 nil or "a" -> "a" nil and 10 -> nil false and error() -> false false and nil -> false false or nil -> nil 10 and 20 -> 20 # «sec3.4.4» # «Concatenation» 3.4.4 Concatenation The string concatenation operator in Lua is denoted by two dots (`..'). If both operands are strings or numbers, then they are converted to strings according to the rules mentioned in (to "sec2.4"). Otherwise, the ``concat'' metamethod is called (see (to "sec3.7")). # «p10» (find-lua50page 10) # «sec3.4.5» # «Precedence» 3.4.5 Precedence Operator precedence in Lua follows the table below, from lower to higher priority: or and < > <= >= ~= == .. + - * / not - (unary) ^ The .. (concatenation) and ^ (exponentiation) operators are right associative. All other binary operators are left associative. # «sec3.4.6» # «Table Constructors» 3.4.6 Table Constructors Table constructors are expressions that create tables; every time a constructor is evaluated, a new table is created. Constructors can be used to create empty tables, or to create a table and initialize some of its fields. The general syntax for constructors is tableconstructor -> `{' [ fieldlist ] `}' fieldlist -> field { fieldsep field } [ fieldsep ] field -> `[' exp `]' `=' exp | Name `=' exp | exp fieldsep -> `,' | `;' Each field of the form [exp1] = exp2 adds to the new table an entry with key exp1 and value exp2. A field of the form name = exp is equivalent to ["name"] = exp. Finally, fields of the form exp are equivalent to [i] = exp, where i are consecutive numerical integers, starting with 1. Fields in the other formats do not affect this counting. For example, a = {[f(1)] = g; "x", "y"; x = 1, f(x), [30] = 23; 45} is equivalent to do local temp = {} temp[f(1)] = g temp[1] = "x" -- 1st exp temp[2] = "y" -- 2nd exp temp.x = 1 -- temp["x"] = 1 temp[3] = f(x) -- 3rd exp temp[30] = 23 temp[4] = 45 -- 4th exp a = temp end If the last expression in the list is a function call, then all values returned by the call enter the list consecutively (see (to "sec3.4.7")). If you want to avoid this, enclose the function call in parentheses. The field list may have an optional trailing separator, as a convenience for machine-generated code. # «p11» (find-lua50page 11) # «sec3.4.7» # «Function Calls» 3.4.7 Function Calls A function call in Lua has the following syntax: functioncall -> prefixexp args In a function call, first prefixexp and args are evaluated. If the value of prefixexp has type function, then that function is called, with the given arguments. Otherwise, its ``call'' metamethod is called, having as first parameter the value of prefixexp, followed by the original call arguments (see (to "sec3.7")). The form functioncall -> prefixexp `:' name args can be used to call ``methods''. A call v:name(...) is syntactic sugar for v.name(v, ...), except that v is evaluated only once. Arguments have the following syntax: args -> `(' [ explist1 ] `)' args -> tableconstructor args -> Literal All argument expressions are evaluated before the call. A call of the form f{...} is syntactic sugar for f({...}), that is, the argument list is a single new table. A call of the form f'...' (or f"..." or f[[...]]) is syntactic sugar for f('...'), that is, the argument list is a single literal string. Because a function can return any number of results (see (to "sec3.3.4")), the number of results must be adjusted before they are used. If the function is called as a statement (see (to "sec3.3.6")), then its return list is adjusted to 0 elements, thus discarding all returned values. If the function is called inside another expression, or in the middle of a list of expressions, then its return list is adjusted to 1 element, thus discarding all returned values but the first one. If the function is called as the last element of a list of expressions, then no adjustment is made (unless the call is enclosed in parentheses). Here are some examples: f() -- adjusted to 0 results g(f(), x) -- f() is adjusted to 1 result g(x, f()) -- g gets x plus all values returned by f() a,b,c = f(), x -- f() is adjusted to 1 result (and c gets nil) a,b,c = x, f() -- f() is adjusted to 2 a,b,c = f() -- f() is adjusted to 3 return f() -- returns all values returned by f() return x,y,f() -- returns x, y, and all values returned by f() {f()} -- creates a list with all values returned by f() {f(), nil} -- f() is adjusted to 1 result If you enclose a function call in parentheses, then it is adjusted to return exactly one value: return x,y,(f()) -- returns x, y, and the first value from f() {(f())} -- creates a table with exactly one element As an exception to the format-free syntax of Lua, you cannot put a line break before the ( in a function call. That restriction avoids some ambiguities in the language. If you write a = f (g).x(a) # «p12» (find-lua50page 12) Lua would read that as a = f(g).x(a). So, if you want two statements, you must add a semi-colon between them. If you actually want to call f, you must remove the line break before (g). # «sec3.4.8» # «Function Definitions» 3.4.8 Function Definitions The syntax for function definition is function -> function funcbody funcbody -> `(' [ parlist1 ] `)' block end The following syntactic sugar simplifies function definitions: stat -> function funcname funcbody stat -> local function name funcbody funcname -> name { `.' name } [ `:' name ] The statement function f () ... end translates to f = function () ... end The statement function t.a.b.c.f () ... end translates to t.a.b.c.f = function () ... end The statement local function f () ... end translates to local f; f = function () ... end A function definition is an executable expression, whose value has type function. When Lua pre-compiles a chunk, all its function bodies are pre-compiled too. Then, whenever Lua executes the function definition, the function is instantiated (or closed). This function instance (or closure) is the final value of the expression. Different instances of the same function may refer to different non-local variables (see (to "sec3.5")) and may have different tables of globals (see (to "sec2.2")). Parameters act as local variables, initialized with the argument values: parlist1 -> namelist [ `,' `...' ] parlist1 -> `...' When a function is called, the list of arguments is adjusted to the length of the list of parameters, unless the function is a vararg function, which is indicated by three dots (`...') at the end of its parameter list. A vararg function does not adjust its argument list; instead, it collects all extra arguments into an implicit parameter, called arg. The value of arg is a table, with a field n whose value is the number of extra arguments, and the extra arguments at positions 1, 2, . . . , n. As an example, consider the following definitions: # «p13» (find-lua50page 13) function f(a, b) end function g(a, b, ...) end function r() return 1,2,3 end Then, we have the following mapping from arguments to parameters: 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, arg={n=0} g(3, 4) a=3, b=4, arg={n=0} g(3, 4, 5, 8) a=3, b=4, arg={5, 8; n=2} g(5, r()) a=5, b=1, arg={2, 3; n=2} Results are returned using the return statement (see (to "sec3.3.4")). If control reaches the end of a function without encountering a return statement, then the function returns with no results. The colon syntax is used for defining methods, that is, functions that have an implicit extra parameter self. Thus, the statement function t.a.b.c:f (...) ... end is syntactic sugar for t.a.b.c.f = function (self, ...) ... end # «sec3.5» # «Visibility Rules» 3.5 Visibility Rules Lua is a lexically scoped language. The scope of variables begins at the first statement after their declaration and lasts until the end of the innermost block that includes the declaration. For instance: 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) # «p14» (find-lua50page 14) Notice that, in a declaration like local x = x, the new x being declared is not in scope yet, so the second x refers to the ``outside'' variable. Because of those lexical scoping rules, local variables can be freely accessed by functions defined inside their scope. For instance: local counter = 0 function inc (x) counter = counter + x return counter end Notice that each execution of a local statement ``creates'' new local variables. Consider the following example: a = {} local x = 20 for i=1,10 do local y = 0 a[i] = function () y=y+1; return x+y end end In that code, each function uses a different y variable, while all of them share the same x. # «sec3.6» # «Error Handling» 3.6 Error Handling Because Lua is an extension language, all Lua actions start from C code in the host program calling a function from the Lua library (see (to "sec4.16")). Whenever an error occurs during Lua compilation or execution, control returns to C, which can take appropriate measures (such as to print an error message). Lua code can explicitly generate an error by calling the function error (see (to "sec6.1")). If you need to catch errors in Lua, you can use the pcall function (see (to "sec6.1")). # «sec3.7» # «Metatables» 3.7 Metatables Every table and userdata value in Lua may have a metatable. This metatable is a table that defines the behavior of the original table and userdata under some operations. You can query and change the metatable of an object with functions setmetatable and getmetatable (see (to "sec6.1")). For each of those operations Lua associates a specific key, called an event. When Lua performs one of those operations over a table or a userdata, if checks whether that object has a metatable with the corresponding event. If so, the value associated with that key (the metamethod) controls how Lua will perform the operation. 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; for instance, the key for operation ``add'' is the string "__add". The semantics of these operations is better explained by a Lua function describing how the interpreter executes that operation. 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 (rawget, tonumber, etc.) are described in (to "sec6.1"). # «p15» (find-lua50page 15) # «__add» ``add'': the + operation. The function getbinhandler 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. function getbinhandler (op1, op2, event) return metatable(op1)[event] or metatable(op2)[event] end Using that function, the behavior of the ``add'' operation is 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("unexpected type at arithmetic operation") end end end # «__sub» ``sub'': the - operation. Behavior similar to the ``add'' operation. # «__mul» ``mul'': the * operation. Behavior similar to the ``add'' operation. # «__div» ``div'': the / operation. Behavior similar to the ``add'' operation. # «__pow» ``pow'': the ^ operation (exponentiation) operation. ?? function pow_event (op1, op2) local h = getbinhandler(op1, op2, "__pow") ??? if h then -- call the handler with both operands return h(op1, op2) else -- no handler available: default behavior error("unexpected type at arithmetic operation") end end # «__unm» ``unm'': the unary - operation. # «p16» (find-lua50page 16) 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 and nil return h(op, nil) else -- no handler available: default behavior error("unexpected type at arithmetic operation") end end end # «__lt» ``lt'': the < operation. function lt_event (op1, op2) if type(op1) == "number" and type(op2) == "number" then return op1 < op2 -- numeric comparison elseif type(op1) == "string" and type(op2) == "string" then return op1 < op2 -- lexicographic comparison else local h = getbinhandler(op1, op2, "__lt") if h then return h(op1, op2) else error("unexpected type at comparison"); end end end a>b is equivalent to b=b is equivalent to b<=a. Notice that, in the absence of a ``le'' metamethod, Lua tries the ``lt'', assuming that a<=b is equivalent to not (b