ing of what they are doing, as most
constructions are explicit in the code.
This explicitness also allows such
deeper understanding. We trust this
is a blessing, not a curse.
1. Cazzola, W. and Olivares, D.M. Gradually learning
programming supported by a growable programming
language. IEEE Transactions on Emerging Topics in
Computing 4, 3 (July 2016), 404–415.
2. de Moura, A.L and Ierusalimschy, R. Revisiting
coroutines. ACM Transactions on Programming
Languages and Systems 31, 2 (Feb. 2009), 6. 1–6. 31.
3. Gamasutra. Game Developer magazine’s 2011 Front
Line Award, Jan. 13, 2012; https://www.gamasutra.
4. Hayes, B. Ephemerons: A new finalization mechanism.
In Proceedings of the 12th ACM SIGPLAN Conference
on Object-Oriented Programming, Systems,
Languages, and Applications (Atlanta, GA, Oct. 5–9).
ACM, New York, 1997, 176–183.
5. Ierusalimschy, R. Programming with multiple
paradigms in Lua. In Proceedings of the 18th
International Workshop on Functional and (Constraint)
Logic Programming, LNCS, Volume 5979. S. Escobar,
Ed. (Brasilia, Brazil, June 28). Springer, Heidelberg,
Germany, 2009, 5–13.
6. Ierusalimschy, R., de Figueiredo, L.H., and Celes, W.
Lua—An extensible extension language. Software:
Practice and Experience 26, 6 (June 1996), 635–652.
7. Ierusalimschy, R., de Figueiredo, L. H., and Celes, W.
The evolution of Lua. In Proceedings of the Third ACM
SIGPLAN Conference on History of Programming
Languages (San Diego, CA, June 9–10). ACM Press,
New York, 2007, 2. 1–2. 26.
8. Ierusalimschy, R., de Figueiredo, L.H., and Celes,
W. Passing a language through the eye of a needle.
Commun. ACM 54, 7 (July 2011), 38–43.
9. International Organization for Standardization.
ISO 2000. International Standard: Programming
Languages, C. ISO/IEC9899: 1999(E).
10. Jones, R., Hosking, A., and Moss, E. The Garbage
Collection Handbook. CRC Press, Boca Raton, FL, 2011.
11. Kats, L. and Visser, E. The Spoofax Language
Workbench: Rules for declarative specification of
languages and IDEs. In Proceedings of the ACM
International Conference on Object Oriented
Programming Systems Languages and Applications
(Reno/Tahoe, NV, Oct. 17–21). ACM Press, New York,
12. The Python Software Foundation. The Python
Language Reference, 3. 5 Edition. The Python Software
13. Sestoft, P. Programming Language Concepts, Second
Edition. Springer, Cham, Switzerland, 2017.
14. Wikipedia. List of applications using Lua; https://
Roberto Ierusalimschy ( email@example.com) is an
associate professor of computer science at PUC-Rio, the
Pontifical Catholic University of Rio de Janeiro, Brazil.
Luiz Henrique de Figueiredo ( firstname.lastname@example.org) is a
researcher at IMPA, the Institute for Pure and Applied
Mathematics in Rio de Janeiro, Brazil.
Waldemar Celes ( email@example.com) is an associate
professor of computer science at PUC-Rio, the Pontifical
Catholic University of Rio de Janeiro, Brazil.
Copyright held by the authors.
Publication rights licensed to ACM. $15.00
the application needs an input, it resumes that coroutine. That is the only
change the programmer needs to
make in the application. The script,
for its part, also looks like a regular program, except it yields when
it needs to send a command to the
application. The control flow of the
resulting program progresses as follows: The application starts, creates
the coroutine, does its own initializa-tion, and then waits for input by resuming the coroutine. The coroutine
then starts running, does its own ini-tialization, and performs its duties
until it needs some service from the
application. At this point, the script
yields with a request, the call to resume made by the application returns, and the application services
the given request. The application
then waits for the next request by resuming the script again.
Presentation of coroutines in
the C API is clearly more challenging than presentation of functions
and tables. C code can create and
resume coroutines without restrictions. In particular, resuming works
like a regular function call: It (re)
activates the given coroutine when
called and returns when the coroutine yields or ends. However, yielding also poses a problem. Once a C
function yields, there is no way to
later return the control to that point
in the function. The API offers two
ways to circumvent this restriction:
The first is to yield in a tail position:
When the coroutine resumes, it goes
straight to the calling Lua function.
The second is to provide a continuation function when yielding. In this
way, when the coroutine resumes,
the control goes to the continuation
function, which can finish the task
of the original function.
We can see again in the API the advantages of asymmetric coroutines for
a language like Lua. With symmetric
coroutines, all transfers would have
the problems that asymmetric coroutines have only when yielding. In our
experience, resumes from C are much
more common than yields.
Every design involves balancing conflicting goals. To address the conflicts,
designers need to prioritize their goals.
This is clearly true of the design of any
Lua has a unique set of design goals
that prioritize simplicity, portability,
and embedding. The Lua core is based
on three well-known, proven concepts—associative arrays, first-class
functions, and coroutines—all implemented with no artificial restrictions.
On top of these components, Lua follows the motto “mechanisms instead
of policies,” meaning Lua’s design
aims to offer basic mechanisms to allow programmers to implement more
complex features. For instance, in the
case of modules, tables provide name
spaces, lexical scoping provides encapsulation, and first-class functions allow
exportation of functions. On top of that,
Lua adds only the function require to
search for and load modules.
Modularity in language design is
nothing new. 11 For instance, it can
be used to clarify the construction
of a large application. 1 However, Lua
uses modularity to keep its size small,
breaking down complex constructions
into existing mechanisms.
The motto “mechanisms instead of
policies” also makes for a flexible language, sometimes too flexible. For instance, the do-it-yourself approach to
classes and objects leads to proliferation of different, often incompatible,
systems, but is handy when a programmer needs to adapt Lua to the class
model of the host program.
Tables, functions, and coroutines as
used in Lua have shown great flexibility
over the years. Despite the language’s
continuing evolution, there has been
little demand from programmers to
change the basic mechanisms.
The lack of built-in complex constructions and minimalist standard
libraries (for portability and small
size) make Lua a language that is not
as good as other scripting languages
for writing “quick-and-dirty” programs. Many programs in Lua need
an initial phase for programmers to
set up the language, as a minimal infrastructure for object-oriented programming. More often than not, Lua
is embedded in a host application.
Embedding demands planning and
the set-up of the language is typically
integrated with its embedding. Lua’s
economy of concepts demands from
programmers a deeper understand-
Watch the authors discuss
this work in the exclusive