wiki

Lua C Closure Example
Lua C Closure Date
Lua C Closure Chart
Lua C Closure Code
Lua C Closure

Functions & Closures In the source code, Lua Functions are called Closure. A Closure is composed of proto and UpVal. A proto is basically a function not yet bound to UpVal.

Closures in Lua. First-class functions are a very powerful language construct and a fundamental feature in functional languages. However, few procedural languages support this feature, due to their stack-based implementation. In this paper we discuss a new algorithm for the implementation of first-class functions used in the implementation of.
Extending Lua in C. Lua is a small, portable, and fast scripting language designed for embedding in other software. Being designed for embedding, it has a simple but powerful API which makes it easy to communicate both ways: from C into Lua and from Lua into C. In this post, I’ll describe the process of writing a small module adding support.
Lua Functions have separate Lua, C and lightweight C subtypes, with this last being a special case where the C function has no upvals and so it doesn't need an associated Closure structure. It is also the same TValue type as our lightweight functions.
C closures don't really have a concept of bound and unbound variables. However, the C closure does have a number of places to put Lua values: transiently on the stack, at a known index or persistently, in order of privateness: in the upvalue array, which is a fixed-length array created as part of the C closure by luapushcclosure.

Introduction

In ten years or more of Lua programming, I have experimented with numerous approaches to Object Orientation (OO) from 'Programming in Lua', 'Lua Programming Gems' and this wiki as well as schemes of my own, some with extensive 'C' support libraries. I have eventually standardised on the scheme outlined in this paper which is very flexible and relatively simple, can be implemented entirely in Lua and possesses some desirable OO characteristics that I've not seen in other Lua implementations.

Desirable OO Characteristics

It is commonly agreed that an OO system should provide encapsulation of multiple values (fields) and functions operating on those fields (methods). It is fairly commonly agreed that the system should provide an easy way of generating multiple objects sharing characteristics (most commonly method implementations). Classes or prototypes are two ways of implementing this.

I also want my classes to be seamless extensions of the Lua type system. In a pure OO language, there would be no distinction between types and classes, but a good compromise for Lua is for classes to be types but not vice versa. Given an unknown Lua value, we will need a function which can determine if it is of a specified class or type.

Another desirable characteristic is inter-working between classes and objects created in 'C' using the Lua API and those created in pure Lua. This allows 'C' libraries to provide classes and functions or methods defined in those libraries to create and return objects. It should ideally also be possible for 'C' code to create objects from classes defined in Lua.

Lua C Closure Example

Classes implemented as Constructor Closures

The crux of the scheme I propose in this paper is that classes are implemented as Lua function closures that return a new object of the class when executed. All the resources required to create an object are stored in upvalues of the class closure or passed as parameters to the closure function. This means that classes are first-class Lua values independent of their storage.

Some characterised upvalues must be present in all classes to support type matching. This is referred to as the TID, for Type ID. It must also be possible to derive a TID value from objects generated by the classes so that a generic predicate function can match an object with its class. By the simple expedient of defining the TID of values which are not classes or objects to be the Lua type name, this scheme can be extended so all Lua values have a TID and can be type-matched using the same predicate function.

A nice consequence of this scheme is a constructor syntax for objects that represent collections. For example, assuming the definition of a class called List, we can write:

This uses a standard Lua syntax shortcut to allow the function call braces to be omitted. Within the List function, we can detect that one parameter has been passed, a table with no metatable (call this a 'rawtable'), and in this case convert it in place into an object without having to copy the entries. I think this seems like a very natural extension of the Lua table constructor syntax. Alternative construction syntaxes can also, or alternatively, be provided using other parameter signatures.

Creating Classes and Objects

Having been quite prescriptive in defining a class implementation, we can be much more flexible about the object implementation whilst still preserving universal type matching. In this section, I will show that the major object patterns suggested in the literature can all be accommodated within this scheme.

Firstly, I will demonstrate a class that produces metatable-based objects. In this pattern, the object is a Lua table (or possibly a userdata if implemented in 'C') with a metatable common to all objects of the same class. The methods and metamethods of the class are stored in this metatable while the fields are stored in the object table. The metatable is also the class TID.

The function class.newmeta() is a simple helper function that creates a new metatable and sets the index metamethod to self-refer. class.istype() is a multi-purpose type testing predicate and class.checkmethod() wraps this test and raises an error if the predicate is false (I will show an implementation of these functions later in this paper). Notice that routine use of class.checkmethod also means that all methods of a class hold upvalue references to the class itself facilitating creation of return parameters of the same class.

To create objects, just call the class:

To support single inheritance, class.newmeta() can be extended to take a parent class. This gets the parent TID (which is also its metatable) and sets it as the metatable of the new metatable (metametatable?). The parent class is also passed through unchanged as a syntax convenience:

Lua C Closure Date

The second pattern I will explore is prototype based. Classically, prototype approaches do not use the concept of 'class' at all; instead any object may act as a prototype for creating further objects. However I will use a standard class 'wrapper' around the prototype object and this will implement the table cloning code. The objects produced are Lua tables which contain the methods as well as the fields. If metamethods are required, a metatable will also be needed. To support type matching, a metatable will always be assigned even if it is empty.

The support function class.newproto() does most of the work in this case. It generates the class (function closure) and also returns references to the prototype table and the metatable ready to be populated. The class function is standardised, providing the functionality to clone the prototype table.

The standard class function takes an optional table parameter which can override (initialise) existing fields after they have been copied from the prototype.

This pattern can accommodate multiple inheritance (aggregation). The function class.newproto() can accept any number of object (table) parameters. These tables, and their metatables are merged to create the prototype table and metatable. Merge is in parameter order, so fields in later parameters override those with the same name in earlier parameters.

Note that in this pattern, inheritance is from an object of the parent class, not from the class itself.

The final pattern I will consider is the single function pattern. This has an object implementation similar to the class implementation (indeed a class is also an object of this type). The object has just one method which forms a closure with the fields