Welcome to Scribd. Sign in or start your free trial to enjoy unlimited e-books, audiobooks & documents.Find out more
Download
Standard view
Full view
of .
Look up keyword
Like this
1Activity
0 of .
Results for:
No results containing your search query
P. 1
The Evolution of Lua

The Evolution of Lua

Ratings: (0)|Views: 4|Likes:
Published by Mikhail Miguel

More info:

Published by: Mikhail Miguel on Feb 12, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

02/12/2012

pdf

text

original

 
The Evolution of Lua
Roberto Ierusalimschy
Department of Computer Science,PUC-Rio, Rio de Janeiro, Brazil
roberto@inf.puc-rio.br
Luiz Henrique de Figueiredo
IMPA–Instituto Nacional deMatem´atica Pura e Aplicada, Brazil
lhf@impa.br
Waldemar Celes
Department of Computer Science,PUC-Rio, Rio de Janeiro, Brazil
celes@inf.puc-rio.br
Abstract
We report on the birth and evolution of Lua and discuss howit moved from a simple configuration language to a versatile,widely used language that supports extensible semantics,anonymous functions, full lexical scoping, proper tail calls,and coroutines.
Categories and Subject Descriptors
K.2 [
 HISTORY OF COMPUTING
]: Software; D.3 [
PROGRAMMING LAN-GUAGES
]
1. Introduction
Lua is a scripting language born in 1993 at PUC-Rio, thePontifical Catholic University of Rio de Janeiro in Brazil.Since then, Lua has evolved to become widely used in allkinds of industrial applications, such as robotics, literateprogramming,distributedbusiness,imageprocessing,exten-sible text editors, Ethernet switches, bioinformatics, finite-element packages, web development, and more[2]. In par-ticular, Lua is one of the leading scripting languages in gamedevelopment.Lua has gone far beyond our most optimistic expecta-tions.Indeed,whilealmostallprogramminglanguagescomefrom North America and Western Europe (with the notableexception of Ruby, from Japan)[4], Lua is the only languagecreated in a developing country to have achieved global rel-evance.From the start, Lua was designed to be simple, small,portable, fast, and easily embedded into applications. Thesedesign principles are still in force, and we believe that theyaccount for Lua’s success in industry. The main characteris-tic of Lua, and a vivid expression of its simplicity, is that itoffers a single kind of data structure, the
table
, which is theLua term for an associative array[9]. Although most script-ing languages offer associative arrays, in no other languagedo associative arrays play such a central role. Lua tablesprovide simple and efficient implementations for modules,prototype-basedobjects,class-basedobjects,records,arrays,sets, bags, lists, and many other data structures [28].In this paper, we report on the birth and evolution of Lua.We discuss how Lua moved from a simple configurationlanguage to a powerful (but still simple) language that sup-portsextensiblesemantics,anonymousfunctions,fulllexicalscoping, proper tail calls, and coroutines. In
§
2we give anoverview of the main concepts in Lua, which we use in theother sections to discuss how Lua has evolved. In
§
3we re-late the prehistory of Lua, that is, the setting that led to itscreation. In
§
4we relate how Lua was born, what its originaldesign goals were, and what features its first version had. Adiscussion of how and why Lua has evolved is given in
§
5.A detailed discussion of the evolution of selected featuresis given in
§
6.The paper ends in
§
7with a retrospective of the evolution of Lua and in
§
8with a brief discussion of thereasons for Lua’s success, especially in games.
2. Overview
In this section we give a brief overview of the Lua languageand introduce the concepts discussed in
§
5and
§
6.For acomplete definition of Lua, see its reference manual [32].For a detailed introduction to Lua, see Roberto’s book [28].For concreteness, we shall describe Lua 5.1, which is thecurrent version at the time of this writing (April 2007), butmost of this section applies unchanged to previous versions.Syntactically, Lua is reminiscent of Modula and usesfamiliar keywords. To give a taste of Lua’s syntax, the codebelow shows two implementations of the factorial function,one recursive and another iterative. Anyone with a basicknowledge of programming can probably understand theseexamples without explanation.
function factorial(n) function factorial(n)if n == 0 then local a = 1return 1 for i = 1,n doelse a = a*ireturn n*factorial(n-1) endend return aend end
 
Semantically, Lua has many similarities with Scheme,even though these similarities are not immediately clear be-cause the two languages are syntactically very different. Theinfluence of Scheme on Lua has gradually increased duringLua’s evolution: initially, Scheme was just a language in thebackground, but later it became increasingly important asa source of inspiration, especially with the introduction of anonymous functions and full lexical scoping.Like Scheme, Lua is dynamically typed: variables do nothave types; only values have types. As in Scheme, a variablein Lua never contains a structured value, only a reference toone. As in Scheme, a function name has no special status inLua: it is just a regular variable that happens to refer to afunction value. Actually, the syntax for function definition
function foo()
···
end
used above is just syntacticsugar for the assignment of an anonymous function to avariable:
foo = function ()
···
end
’.LikeScheme,Luahas first-class functions with lexical scoping. Actually, allvalues in Lua are first-class values: they can be assignedto global and local variables, stored in tables, passed asarguments to functions, and returned from functions.One important semantic difference between Lua andSchemeand probably the main distinguishing feature of Luais that Lua offers
tables
as its sole data-structuringmechanism. Lua tables are associative arrays[9], but withsome important features. Like all values in Lua, tables arefirst-class values: they are not bound to specific variablenames, as they are in Awk and Perl. A table can have anyvalue as key and can store any value. Tables allow sim-ple and efficient implementation of records (by using fieldnames as keys), sets (by using set elements as keys), genericlinked structures, and many other data structures. Moreover,we can use a table to implement an array by using naturalnumbers as indices. A careful implementation[31] ensuresthat such a table uses the same amount of memory that anarray would (because it is represented internally as an actualarray) and performs better than arrays in similar languages,as independent benchmarks show [1].Lua offers an expressive syntax for creating tables inthe form of 
constructors
. The simplest constructor is theexpression ‘
{}
’, which creates a new, empty table. There arealso constructors to create lists (or arrays), such as
{"Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"}
and to create records, such as
{lat= -22.90, long= -43.23, city= "Rio de Janeiro"}
These two forms can be freely mixed. Tables are indexedusing square brackets, as in ‘
t[2]
’, with ‘
t.x
’ as sugar for
t["x"]
’.The combination of table constructors and functionsturns Lua into a powerful general-purpose procedural data-description language. For instance, a bibliographic databasein a format similar to the one used in BibTEX [34] can bewritten as a series of table constructors such as this:
article{"spe96",authors = {"Roberto Ierusalimschy","Luiz Henrique de Figueiredo","Waldemar Celes"},title = "Lua: an Extensible Extension Language",journal = "Software: Practice & Experience",year = 1996,}
Although such a database seems to be an inert data file,it is actually a valid Lua program: when the database isloaded into Lua, each item in it invokes a function, because
article{
···
}
’ is syntactic sugar for ‘
article({
···
})
’,that is, a function call with a table as its single argument.It is in this sense that such files are called procedural datafiles.We say that Lua is an extensible extension language [30].It is an
extension language
because it helps to extend ap-plications through configuration, macros, and other end-usercustomizations. Lua is designed to be embedded into a hostapplication so that users can control how the application be-haves by writing Lua programs that access application ser-vices and manipulate application data. It is
extensible
be-cause it offers
userdata
values to hold application data and
extensible semantics
mechanisms to manipulate these valuesin natural ways. Lua is provided as a small core that can beextended with user functions written in both Lua and C. Inparticular, input and output, string manipulation, mathema-tical functions, and interfaces to the operating system are allprovided as external libraries.Other distinguishing features of Lua come from its im-plementation:
Portability
: Lua is easy to build because it is implementedin strict ANSI C.
1
It compiles out-of-the-box on mostplatforms (Linux, Unix, Windows, Mac OS X, etc.), andruns with at most a few small adjustments in virtuallyall platforms we know of, including mobile devices (e.g.,handheld computers and cell phones) and embedded mi-croprocessors (e.g., ARM and Rabbit). To ensure porta-bility, we strive for warning-free compilations under asmany compilers as possible.
 Ease of embedding
: Lua has been designed to be easilyembedded into applications. An important part of Lua isa well-defined application programming interface (API)that allows full communication between Lua code andexternal code. In particular, it is easy to extend Lua byexporting C functions from the host application. The APIallows Lua to interface not only with C and C++, but alsowith other languages, such as Fortran, Java, Smalltalk,Ada, C# (.Net), and even with other scripting languages(e.g., Perl and Ruby).
1
Actually, Lua is implemented in “clean C”, that is, the intersection of Cand C++. Lua compiles unmodified as a C++ library.
 
Small size
: Adding Lua to an application does not bloat it.The whole Lua distribution, including source code, doc-umentation, and binaries for some platforms, has alwaysfit comfortably on a floppy disk. The tarball for Lua 5.1,which contains source code, documentation, and exam-ples, takes 208K compressed and 835K uncompressed.The source contains around 17,000 lines of C. UnderLinux, the Lua interpreter built with all standard Lua li-braries takes 143K. The corresponding numbers for mostother scripting languages are more than an order of mag-nitude larger, partially because Lua is primarily meant tobe embedded into applications and so its official distri-bution includes only a few libraries. Other scripting lan-guages are meant to be used standalone and include manylibraries.
 Efficiency
: Independent benchmarks [1] show Lua to beone of the fastest languages in the realm of interpretedscripting languages. This allows application developersto write a substantial fraction of the whole applicationin Lua. For instance, over 40% of Adobe Lightroom iswritten in Lua (that represents around 100,000 lines of Lua code).Although these are features of a specific implementation,they are possible only due to the design of Lua. In particular,Lua’s simplicity is a key factor in allowing a small, efficientimplementation [31].
3. Prehistory
Lua was born in 1993 inside Tecgraf, the Computer Graph-ics Technology Group of PUC-Rio in Brazil. The cre-ators of Lua were Roberto Ierusalimschy, Luiz Henriquede Figueiredo, and Waldemar Celes. Roberto was an assis-tant professor at the Department of Computer Science of PUC-Rio. Luiz Henrique was a post-doctoral fellow, first atIMPA and later at Tecgraf. Waldemar was a Ph.D. student inComputer Science at PUC-Rio. All three were members of Tecgraf, working on different projects there before gettingtogether to work on Lua. They had different, but related,backgrounds: Roberto was a computer scientist interestedmainly in programming languages; Luiz Henrique was amathematician interested in software tools and computergraphics; Waldemar was an engineer interested in appli-cations of computer graphics. (In 2001, Waldemar joinedRoberto as faculty at PUC-Rio and Luiz Henrique became aresearcher at IMPA.)Tecgraf is a large research and development laboratorywith several industrial partners. During the first ten yearsafter its creation in May 1987, Tecgraf focused mainly onbuildingbasicsoftwaretoolstoenableittoproducetheinter-activegraphicalprogramsneededbyitsclients.Accordingly,the first Tecgraf products were drivers for graphical termi-nals, plotters, and printers; graphical libraries; and graphicalinterface toolkits. From 1977 until 1992, Brazil had a pol-icy of strong trade barriers (called a “market reserve”) forcomputer hardware and software motivated by a national-istic feeling that Brazil could and should produce its ownhardware and software. In that atmosphere, Tecgraf’s clientscould not afford, either politically or financially, to buy cus-tomized software from abroad: by the market reserve rules,they would have to go through a complicated bureaucraticprocess to prove that their needs could not be met by Brazil-ian companies. Added to the natural geographical isolationof Brazil from other research and development centers, thosereasons led Tecgraf to implement from scratch the basictools it needed.One of Tecgraf’s largest partners was (and still is) Petro-bras, the Brazilian oil company. Several Tecgraf productswere interactive graphical programs for engineering appli-cations at Petrobras. By 1993, Tecgraf had developed littlelanguages for two of those applications: a data-entry appli-cation and a configurable report generator for lithology pro-files. These languages, called DEL and SOL, were the an-cestors of Lua. We describe them briefly here to show whereLua came from.
3.1 DEL
The engineers at Petrobras needed to prepare input data filesfor numerical simulators several times a day. This processwas boring and error-prone because the simulation programswere legacy code that needed strictly formatted input filestypically bare columns of numbers, with no indication of what each number meant, a format inherited from the daysof punched cards. In early 1992, Petrobras asked Tecgraf tocreate at least a dozen graphical front-ends for this kind of data entry. The numbers would be input interactively, justby clicking on the relevant parts of a diagram describingthe simulation—a much easier and more meaningful task for the engineers than editing columns of numbers. Thedata file, in the correct format for the simulator, would begenerated automatically. Besides simplifying the creation of data files, such front-ends provided the opportunity to adddata validation and also to compute derived quantities fromthe input data, thus reducing the amount of data needed fromthe user and increasing the reliability of the whole process.To simplify the development of those front-ends, a teamled by Luiz Henrique de Figueiredo and Luiz CristoaoGomes Coelho decided to code all front-ends in a uni-form way, and so designed DEL (“data-entry language”),a simple declarative language to describe each data-entrytask[17].DELwaswhatisnowcalledadomain-specificlan-guage [43], but was then simply called a little language [10]. A typical DEL program defined several “entities”. Eachentity could have several fields, which were named andtyped. For implementing data validation, DEL had predi-cate statements that imposed restrictions on the values of entities. DEL also included statements to specify how datawas to be input and output. An entity in DEL was essen-tially what is called a structure or record in conventional

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->