Like the original LISP, Lua treated nil as false
and everything else as true. The problem is that nil
also represents an unitialized variable. There was no
way to distinguish between an unitialized variable from
a false variable. So, we needed a false value, to make
that distinction possible. But the true value was use-
less; a 1 or any other constant was good enough.
I guess this is a typical example where our “indus-
trial” mind conflicted with our “academic” mind. A
really pragmatic mind would add the Boolean type
without thinking twice. But our academic mind was
upset by this inelegance. In the end the pragmatic side
won, but it took some time.
What were the most important Lua features,
other than the preprocessor, that later became
recognized as misfeatures and were removed from
the language? I do not remember other big misfea-
tures. We did remove several features from Lua, but
mostly because they were superseded by a new, usually
“better” in some sense, feature. This happened with tag
methods (superseded by metamethods), weak refer-
ences in the C API (superseded by weak tables), and
upvalues (superseded by proper lexical scoping).
When a new feature for Lua that would break
backward compatibility is considered, how is that
decision made? These are always hard decisions.
First, we try to find some other format that could avoid
or at least reduce the incompatibility. If that is not
possible, we try to provide easy ways around the incom-
patibility. (For instance, if we remove a function from
the core library we may provide a separated implemen-
tation that the programmer may incorporate into her
code.) Also, we try to measure how difficult it will be to
detect and correct the incompatibility. If the new fea-
ture creates syntax errors (e.g., a new reserved word),
that is not that bad; we may even provide an automatic
tool to fix old code. However, if the new feature may
produce subtle bugs (e.g., a preexisting function return-
ing a different result), we consider it unacceptable.
Were iterator methods, like those of Ruby, con-
sidered for Lua, rather than the for statement
that was added? What considerations led to the
choice? They were not only considered, they were
actually implemented! Since version 3.1 (from 1998),
Lua has had a function “foreach”, that applies a
given function to all pairs in a table. Similarly, with
“gsub” it is easy to apply a given function to each
character in a string.
Instead of a special “block” mechanism for the
iterator body, Lua has used first-class functions for the
task. See the next example:—'t' is a table from names to values
—the next "loop" prints all keys with
values greater than 10
foreach(t, function(key, value)
if value > 10 then print(key) end
end)However, when we first implemented iterators, func-
tions in Lua did not have full lexical scoping. Moreover,
the syntax is a little heavy (macros would help). Also,
exit statements (break and return) are always confus-
ing when used inside iteration bodies. So, in the end we
decided for the for statement.
But “true iterators” are still a useful design in Lua,
even more now that functions have proper lexical scop-
ing. In my Lua book, I end the chapter about the for
statement with a discussion of true iterators.
Can you briefly describe what you mean when
you describe Lua as an extensible extension lan-
guage? It is an “extensible language” because it is
easy to register new functions and types defined in other
languages. So it is easy to extend the language. From a
more concrete point of view, it is easy to call C from Lua.
It is an “extension language” because it is easy to
use Lua to extend an application, to morph Lua into
a macro language for the application. (This is “script-
ing” in its purer meaning.) From a more concrete point
of view, it is easy to call Lua from C.
Data structures have evolved from arrays, records,
and hashes to combinations of these. Can you
estimate the significance of Lua’s tables in the
evolution of data structures in programming
languages? I do not think the Lua table has had any
significance in the evolution of other languages. Maybe
that will change in the future, but I am not sure about
it. In my view, the main benefit offered by Lua tables
is its simplicity, an “all-in-one” solution. But this sim-
plicity has its costs: For instance, static analysis of
Lua programs is very hard, partially because of tables
being so generic and ubiquitous. Each language has its
own priorities.275