Declarative programming offers several advantages in terms of compactness and modularity. Logic programming and rule-based systems are often chosen for tasks such as social simulation because their use of declarative rules and predicates map well to rules of social engagement. Unfortunately, declarative programming is often quite slow, making it inappropriate for large systems or highfrequency updates. This is partly because of its use of search algorithms, but also because of its heavy use of pointer chasing, dynamic allocation, garbage collection, and runtime type-checking. In this paper, we discuss how bottom-up execution of logic programs can be implemented without these issues. We argue that character simulation is a “sweet spot” for bottom-up logic programming, allowing character behavior to be specified in terms of declarative rules, while offering performance competitive with Python systems such as Talk of the Town. We present a language, TED, which offers very good performance and has been used both in research and in an unannounced commercial game.
Simulations, including games, involve iterating through data structures representing the world state, updating the various components of the world and looking for pairwise interactions between them.
For example, needs-based AI [
Best score = 0
Score += S(c, o, n)
Best object = o Best score = score
This has running time ( ). In an effort to optimize it, the programmer might maintain separate, dynamic lists of just the characters that need to be updated, just the objects that are available to satisfy a specific need, etc. This comes at the cost of having to modify other parts of the program to maintain these lists, increasing development costs and dependencies between modules.
Ideally, one would be able to specify the
fundamental computation being performed
(maximization) separately from the choice of data
structures, as one does in relational databases: queries
are expressed in terms of a set of logical data
structures (relational tables). The physical layout of
the data can be adjusted independently to best support
the mix of queries needed. As those queries inevitably
change, the physical data structures can be changed to
support them. Similar arguments have been made in
the context of entity-component systems for massively
online games [
In this paper, we describe a high-performance declarative programming language, TED that can compactly express the algorithm above in two lines of code (see figure 1). Moreover, it can be optimized declaratively as in a relational database, by providing annotations about how to index the data. TED is highly performant, running with minimal dynamic allocation, type checking, or pointer chasing. It also supports parallel execution. We also briefly describe a city simulator built using TED. // Assume C[x], O[x], N[x] mean x is a character, object, or need, respectively // Score[c, o, t] means t is the total score for object o and character c var Score = Definition("Score", c, o, t).If(O[o], t==Sum(s, And[N[n], s==S[c,o,n])); // B[c,o] means c is a character whose best object is o. var B = Predicate("B", c, o).If(C[c], Maximal(o, t, Score[c, o, t]));
Logic programming is a family of declarative programming techniques that involve describing a program in terms of a set of predicates (relations) and rules for computing them.
A rule gives a set of conditions implying the truth of a predicate. For example, siblinghood could be defined in terms of shared parentage:
This states that for any , , and , the sibling relationship holds if both parent relationships hold.
Although not always expressed in the form of logic
programming, symbolic rules have frequently been
used to describe character behavior and social physics
in systems such as Inform 7 [
Classical logic-programming languages such as Prolog
[
Using a rule involves matching the rule’s variables to the arguments specified in the call. For example, the call Sibling["Bill", s], i.e. “who is a sibling of Bill?”, matches the rule above to yield the substitution:
The system then recursively executes the call Parent["Bill",p]. If there was another rule that stated Jenny was one of Bill’s parents, then executing this query would set the variable to “Jenny”, meaning that the second call is really Parent[s,"Jenny"]. If there is a rule that says Jenny is a parent of Christine, then this call would set to Christine. The rule proves Sibling[“Bill”, s] is true and provides Christine as the value of . Further solutions (further siblings) can be found by backtracking the proof process.
Top-down execution computes one solution at a
time, which is an advantage when only one is needed.
On the other hand, if the same call is performed
2 For database queries, it is possible to transform a query into an
equivalent query that, when executed bottom-up is as efficient as
topdown execution using the so-called magic sets algorithm [
Suppose we had already computed the full extension (all the child/parent pairs) of the Parent relation and stored them in an array. In that case, the Sibling rule above could be computed with the following loop: for each (x,p) in Parent for each (y, p2) in Parent if p == p2
return (x,y) Indeed, we could compute an array of all the Siblings, with a small modification: for each (x,p) in Parent for each (y, p2) in Parent if p == p2
After execution of this loop, Sibling contains all the sibling pairs. This has the obvious disadvantages that:
There may be quite a lot of sibling pairs You may only care about the siblings of Bill, in which case the effort to compute the other families is wasted.2 However, it also has several advantages:
Unification can be replaced with if’s and assignments to C-like variables.
Subsequent calls to Sibling can simply check the array; rules are executed only once.
Indexing can be used to speed access to the array.
What to index can be decided after the rules are written and evolve during the life cycle of the game.
This suggests an alternative execution strategy:
compute the complete extensions of each predicate,
and place them in arrays, ensuring before executing a
rule, we first make sure the predicates it references
have been computed. This is known as bottom-up
execution, and is the strategy used in Datalog [
.If(Grid[loc, __], count==Count(And[Neighbor[loc, neighbor], Grid[neighbor, true]])); // Update table: cell dies if over/underpopulated neighborhood Grid.Set(loc,occupied,false).If(Grid[loc,true],Neighbors[loc,count],(count<2|count>3)); // Update table: cell born if empty and 3 neighbors Grid.Set(loc, occupied, true).If(Neighbors[loc, 3]); believe character simulation is a “sweet spot” for bottom-up logic programming: it is often defined in terms of rules, and the engine generally does have to compute complete extensions anyway.
There are many reasons why it’s appealing to be able to treat a simulation as a database that one can query using a query language. One reason is it makes the state of the simulation easily inspectable, and so hopefully debuggable, because everything is already stored in tables that can be queried by the user.
The motivating example for this work is Ryan’s
[
This paper began from the question: what if the
query language could also be the simulation language?
That is, can we write the character simulation logic for
games like The Sims [
The basic structure of such a simulation is as follows. In the foregoing we will generally use the terms predicate and table interchangeably, since most predicates are represented at runtime as tables. Simulations use three main types of tables: • • •
Base tables store the state of the simulation. They retain their data from one simulation step to the next, except insofar as they’re modified by update tables, below.
Derived tables are defined in terms of other tables (base or derived) using rules. Derived tables are recomputed on every step of the simulation.
Update tables list modifications to be made to different base tables at the end of the current simulation step. They are themselves a kind of derived table defined by rules.
As with relational database systems, tables can optionally be indexed by different columns (predicate arguments), making it faster to perform lookups.
TED is a high-performance, bottom-up logic programming language intended for character simulation in AI-heavy games. It is strongly-typed, supports higher-order predicates, metaprogramming, and parallel execution. It includes an optional runtime parser-evaluator that allows users to make live queries against an executing simulator.
TED is embedded in C#, meaning that TED code is C# code that builds the TED program in memory. This has several advantages: • • •
Good interoperability between TED and C#. TED code can easily call into C#, and C# code can easily access the contents of TED tables. IDE support for C#, such as type and syntax checking, colorization, and refactoring automatically extends to TED.
C# can be used as a macro language for metaprogramming; higher-level abstractions can be written as C# code that builds the necessary TED tables and rules.
TED by itself is strictly less expressive than Prolog: it does not allow recursion (see section 5.3) and it does not allow Prolog “functors” (composite objects are opaque to TED’s pattern matcher). Unlike datalog, TED can call arbitrary C# code, which is Turingcomplete. But it still would not be a natural choice to use to implement algorithms such as symbolic integration or natural language generation, that require manipulating tree structures representing symbolic expressions. In exchange for this limitation, we get high performance and parallelizability.
Figure 2 shows Conway’s Game of Life [
The first statement creates a new predicate object (table) and stores it in the C# variable Grid. It holds the state of the board. The predicate has two arguments, location and whether the location is occupied by a cell, and its table representation has two corresponding columns. It’s a base table; it retains its state from tick to tick except as specified by the Set() methods at the end. We will talk about .Set() and the the .Key and .Indexed annotations shortly.
The second statement also defines a table and stores it in a C# variable, NeighborCells. This table maps locations in the grid to the number of cells surrounding them. Unlike Grid, this statement calls the predicate’s .If() method to add a rule to the predicate: NeighborCells[loc,count] is true if: • •
Grid[loc, __], i.e. loc is a location on the board (__ignores that argument), and count==Count(And[…]), i.e. count is the number of solutions to the And[…] query, which finds neighbors of loc that have cells. Since NeighborCells has a rule, it’s a derived table; its table is erased and recomputed on each tick.
The last two statements call the .Set() method of the Grid predicate. The Set() method creates and returns a new predicate, which is a table of rows to be updated. The two calls create two such tables. The .If() method called at the ends of the statements adds rules to those tables, causing it to recompute those tables, and hence the grid locations to modify, on each tick, based on their respective rules. The first rule says to set the occupied column of any location with less than 2 or more than 3 neighbors to false; it “kills” the cell. The second rule says to set the occupied column for locations with exactly 3 neighbors to true; it spawns cells.
The control flow of the overall program is as follows: repeat forever recompute NeighborCells based on Grid recompute table of cells to destroy recompute table of cells to create update Grid based on update tables Let’s look in detail at the rule in the third statement, which says to kill a cell at location loc if: • • •
There’s a cell at loc,
It’s neighbor count is count, (count<2|count>3)
And the count is outside the desired range
Remember this is making a table of cells to kill that will be rebuilt each tick. The naïve execution algorithm for this would be: clear the table for each (loc1, occupied) in Grid if occupied == true for each (loc2, count)
in NeighborCells if loc1==loc2 if (count<2||count>3)
add loc1 to the table On the positive side, the .If() rule is considerably more compact than the equivalent code above, which is generally a good thing. However, it exhaustively searches the NeighborCells table each time it tries to look up the count for a specific location; for grid cells, the algorithm is ( 2). So on the face of it, the logic program is a terrible idea.
We can speed this rule up by indexing the tables so
they don’t need to be scanned. The .Key and
.Indexed annotations in the declarations of Grid an
NeighborCells tell the system to index the tables by
the specified columns. In the .Key case, the annotation
also promises that the values in that column will be
unique; no two rows can have the same key. Key
indices map column values to single rows. Non-key
indices map values to sets of rows. Both rows list
location as a key; given a location, we can find its row
in (1) time. They also index their second column; we
can get the sets of rows with/without cells or rows
with a given number of neighbors, in (1) time. Using
indexing, the rule above effectively executes as:
clear the table
foreach (loc, _) in Grid.Index[
add loc to the table
Here, predicate.Index[columnNumber] is the
index for the specified column. It’s a hash table
mapping column values to rows (key index) or linked
lists of rows (non-key). So Grid.Index[
While still not the preferred way to implement Life, it’s efficient enough to run at 120Hz on a single core of an i9-9900K, including Unity’s graphics code.
Logic programming lets us write loops declaratively: the iteration structure is implicit in the conditions listed in a rule. By precomputing results and storing them in tables, bottom-up logic programming lets us optimize declaratively. Indices can be added to tables incrementally during development, as new access patterns are introduced. Crucially, adding indices requires only adding an annotation to the predicate declaration; no other action is required. Rules need no modification.
As discussed, a TED program is a C# program builds the run-time representation of the TED program, then calls into it as necessary. Declarations create syntax trees representing the code, then preprocess them to create the run-time representation used by the interpreter. Predicates, calls, rules, etc. are all represented at run-time as typed C# objects.
TED relies on liberal use of operator overloading to make TED code look as natural as possible, even though it is “really” a series of constructor calls for syntax trees. Square brackets denote calls to predicates (C# allows the bracket operator to be overloaded, but not the call operator).
Following the terminology used in logic and logic programming, the expressions used as arguments to predicates are known as terms.
Since, again, TED code is really C# code that builds the syntax tree for the TED code to be executed, a term such as x+1 is represented as a data structure such as: var x = new Var<int>("x"); new FunctionalExpression<int>(Add, x, new Constant<int>(1)) However, overloading allows the programmer to type x+1 and have it converted to the constructor call above. The programmer can largely ignore the internal representation.
The one place the programmer does need to be aware of terms and their data types is with variables. As shown above, a TED variable is represented as a C# object of type Var<T> where T is the type of the variable’s value. Before using a variable in a rule:
P[x].If(Q[x]); which states that P is true of a value x if Q is true of it, the programmer needs to first define x as a C# variable containing a TED variable, as with the declaration above. Since this is somewhat cumbersome, it can be shortened to:
var x = (Var<int>)"x"; The declaration specifies both the name of the variable and its type. Once a variable is defined, it can be used in multiple rules, but is treated as a separate local variable for each rule. While the declaration syntax is annoying, one can keep the number of variable declarations to a manageable level.
Note that the program fragment shown in figure 2, uses the variables loc, neighbor, occupied, and count. The declarations for these were withheld until now and are as follows (Vector2Int is Unity’s standard data type for grid locations): var loc = (Var<Vector2Int>)"loc"; var neighbor = (Var<Vector2Int>)"…"; var occupied = (Var<bool>)"occupied"; var count = (Var<int>)"count";
Predicates are C# objects of type Predicate<T1, T2, …, Tn>, where is the number of arguments to the predicate and the are their respective types. The predicates we’ve discussed so far are table predicates. They are represented as tables, and queries to them are implemented as searches on the table and its indices. Table predicates have a .If() method to add rules to them. Table predicates are created using the Predicate method:
Predicate(name, arg1, arg2, …, argn) where name is a string used for identifying the predicate in error messages, and the argi are variables with the desired types for each argument (these jointly define the type of the predicate). Thus the declaration: var Grid=Predicate("Grid",loc,occupied); sets Grid to a Predicate<Vector2Int, bool>, i.e. a predicate with Vector2Int and a bool arguments.
In addition to table predicates, there are primitive predicates, which are directly implemented as C# methods. TED includes many built-in primitives, such as the < operator, used in figure 2.
Finally, TED allows definitions, predicates defined by rules that are inlined into any calls. For example, var CellAt = Definition(“CellAt”, loc) .If(Grid[loc, true]) states that CellAt is a predicate over a Vector2Int, but queries of the form CellAt[ ] should be replaced by the query Grid[ , true].
Procedure calls in Prolog and TED are called goals. Applying a predicate to a set of terms of the correct types returns a Goal object: the syntax tree for a call. Goals for table predicates include an If(Goal…) method that takes a series of other Goals as arguments, constructs a rule from them, and adds the rule to the original Goal’s predicate. Our example declaration:
P[x].If(Q[x]); creates a rule object stating that ∀ . ( ) → ( ), and adds it to the list of P’s rules. For convenience, table predicates also have their own If methods, allowing rules to be combined with predicate definition. Thus: var P = Predicate("P", x).If(Q[x]); is equivalent to: var P = Predicate("P", x);
P[x].If(Q[x]);
Higher-order predicates are predicates parameterized by goals or other predicates. TED includes a number of these, as well as facilities for defining one’s own. Table predicates cannot be higher order.
Definitions and primitive predicates can be made higher order, simply by having one of their arguments be of type Goal. TED includes a number of built-in higher-order primitives: • • • •
Logical connectives: And[], Or[], and Not[] Optimization primitives: Maximal and Minimal, as used in Figure 1.
Flow-control predicates that execute the goal in some modified manner, such as Once[].
Aggregation functions: Count, Sum, and Aggregate as used in Figure 2.
User-defined higher-order primitive predicates are allowed but are currently more involved to write than other user-defined primitives.
Operators map tables to tables. They encapsulate algorithms that execute over a table as a whole, returning a new table as a result. One example is CountsBy, which makes pivot tables. If the table Population is a table of characters in the game and it has a column called sex, then the declaration: var Demographics =
defines a new Predicate<sex,int>, listing the number of characters with each sex in the current step of the simulation.
Most other operators encapsulate graph algorithms. For example, if R is a table predicate of type Predicate<T,T> for some T, for example, representing the edges in a graph whose vertices are objects of type T, then:
var RStar = Closure("R*", R); makes a new predicate, RStar, also of type Predicate<T,T>, such that RStar[ , ] holds iff is reachable from via edges in R.
A number of operators implement different forms of graph matching. If Interested is a Predicate<Person,Person> describing who is interested in dating whom, then:
var D = MatchRandomly("D", Interested); makes a new table, D, that on any step of the simulation contains a subset of the rows of Interested such that no person is listed in two different rows. If we add another column to Interested specifying a level of interest, then:
var D = MatchGreedily("D", Interested); will attempt to choose a matching with the highest interest levels possible (although it not necessarily globally optimal).
If Interested is a relation not between people, but between people and jobs (so it is of type Predicate<Person,Job,float>), and if Capacity is a Predicate<Job,int> listing how many openings there are for each Job, then var E = AssignGreedily("A",
makes a new table, E, matching people to jobs with the highest possible interest level, without assigning more to a job than there are openings.
Base tables can be updated by providing tables of changes to perform.
If is a base table of type Predicate<T1, …, Tn>, then .Add is a table of the same type whose rows are appended to at the end of each simulation step. Thus, .Add.If(…), which adds a rule to .Add, effectively specifies a rule for when to add a row to . There is not presently a .Delete, but there are plans to add it.
Individual columns can be changed by providing tables of changes to make. .Set(key, updateColumn), where key and updateColumn are columns of , i.e. variables specified in ’s definition, returns a table with the columns key and updateColumn. At the end of each update step, the system will iterate through the rows of the .Set table, and for each row, use ’s index to find the row in with the specified key, then change the value of that row’s updateColumn to the value listed in the .Set table. Thus, the rule:
Population.Set(who, status)
.If(Died(who), status=Status.Dead) Would update the status column of the Population table for someone who dies to Status.Dead.
Every TED program has two built-in base tables. Exceptions lists all the exceptions that have been thrown while running rules, together with the tables and rules that threw them. Problems lists invariants and other assertions that have been violated. To declare an invariant, simply write a rule of the form:
If the rule ever succeeds, it will add a line to the Problems table listing Table, the rule, and the values of all variables in the rule. Problem rules are like assertions in other languages in that checking of them can be enabled and disabled and they impose no runtime penalty when disabled. Unlike most languages, however, TED problem rules can be enabled and disabled at run-time without recompilation.
TED is highly optimized. Most code can run without run-time type checks or storage allocation, apart from the initial allocation or reallocation of the tables themselves.
Table data for a Predicate<T1, …, Tn> is stored in a packed array of tuples of type (T1, …, Tn), one per table row. Tuples are value types; they are stored inline in the array, rather than separately represented in the heap. This means table data is stored as a contiguous sequence of bytes, without boxing. Moreover, tables are almost always scanned in order, so table operations have best-case cache locality.
Table operations are optimized to avoid copying of value types. Generics are used for most table operations, to avoid the need for boxing or run-time type checking. Compiled code therefore looks largely like what one would get with hand-written C code, apart from the use of out-of-line calls for things like equality comparison.
For derived tables, which are recomputed on each simulation step, the array is reused from step to step. When table data overflows the array, the array size is doubled, guaranteeing amortized (1) performance.
Indices are implemented as custom hash tables mapping keys to row numbers. To maximize cache performance, the current implementation uses direct addressing with linear probing. To avoid clustering, the hash tables keep their load factors below 0.5, making clustering unlikely. Indices use 8 bytes per row per index, for key indices, 12 for general indices.
Tables can also be declared to have unique rows (i.e. they are sets rather than multisets). They maintain a hash set of all rows and ignore duplicate additions.
A rule, created using the If() method, is specified by a Goal object, known as its head, that forms its conclusion, and a sequence of Goals, known as its body, that form its conditions. The actual internal representation of a rule consists of a series of iterators for each goal in the body. Rules are transformed into their iterators through a preprocessing mechanism.
Goals, such as P[x, y, 7], are matched against tuples
in tables using unification [
In Datalog-like languages, including TED, unification is only performed between goals and table tuples that cannot contain variables. Variables can therefore only be unified with data values, not other variables, removing the need to track aliases.
Variables therefore behave much like C variables; they are simply typed locations in memory. The first time a variable is unified with a value, that value is stored in the location. This is referred to as write mode. Subsequent uses of the variable later in the rule, where the variable is unified with other data values, is implemented by testing equality between the previously stored value and the new value. This is referred to as read mode.
For example, the goal P[x, x, 1] can be unified with a tuple ( , , ) from P’s table by first storing in x, then testing if that stored value is equal to , and finally testing whether = 1. It’s essentially equivalent to the C# code: bool CanUnifyXX1(int a, int b, int c) { x = a; return x == b && c == 1; } Running this against a particular , , , tests if they’re unifiable, while updating x to its new value. It requires no binding lists, pointer chasing, or type checking. It’s much faster than the general unification algorithm.
This is the general approach used for unification in TED. The body of a rule is scanned and the first (leftmost) occurrence of each variable is found and marked write mode. All other variable occurrences, as well as constants, are read mode. A goal unifies with a tuple if each goal argument unifies with its respective tuple element. A write-mode variable aways successfully unifies, and updates the variable. A readmode variable or constant unifies with a value only if they are equal.
The first step of preprocessing is to reduce the rule body to a normal form in which: • • •
Functional expressions are hoisted out of calls to predicates other than the built-in primitive predicate Eval[]. Thus, P[x+1] is transformed to: And[Eval[t,x+1],P[t]] Calls to And[] and Or[] are flattened; that is, And[a, And[b, c]] is simplified to And[a, b, c].
Any goals that can be partially evaluated are reduced to simpler goals. If their truth values are known at preprocessing time, they are replaced with true or false. This includes simplifying And, Or, and Not. It is possible for a body to simplify down to just false, in which case an warning is printed.
Finally, the Goals of the body, which again are just syntax trees, are mapped to iterators to be executed at runtime. For goals involving primitive predicates, the primitive implements its own custom iterator. The preprocessor leaves it to the primitive to choose it.
For table predicates, the iterator must iterate through the rows of the table, unify them with the arguments in the goal, and generate only the ones that match. The preprocessor attempts to choose iterators that use indices when possible. In decreasing order of preference, these are: • • • •
If the table is declared to have unique rows and all goal arguments are read-mode, then the goal is implemented as a single test against the table’s hash-set of rows, with no iteration or unification. If the table has a key index for a read-mode argument in the goal, the goal is implemented as a lookup of this row and a single test of whether it unifies with the arguments.
If the table has a non-key index for a read-mode argument, the goal is implemented as lookup of the linked list of rows with the specified column value, followed by an iteration over those rows, unifying them with the arguments.
If no index is available, the goal is implemented as an iteration over all rows of the table, attempting to unify each with the goal arguments. There is no hinting mechanism to allow the programmer to advise the system on how to choose between multiple non-key indices at present. Nor is there a way to make combined indices over multiple columns. However, these are planned additions.
Execution consists of running the iterators in order. When an iterator succeeds, it updates any write-mode variables it unified with the selected table row, and execution proceeds to the next iterator. When an iterator fails, execution backs up to the previous iterator which generates its next match, if any.
When the last iterator succeeds, all variables have been matched to values during the unification process. The system forms a tuple from the arguments in the head goal, fills it in with the values of the relevant variables, and appends it to the table. It then returns to the last goal’s iterator to generate the next tuple, which may involve the last iterator failing, and asking for the next solution from the previous iterator, which may fail, etc.
When the first iterator fails, the rule has generated all its tuples for the predicate and execution is complete.
Simulation proceeds by repeatedly recomputing derived predicates, then updating base predicates. Recomputation of a derived predicate works by recursively updating the predicates used its rules, if they haven’t already been updated, then recomputing the table for the derived predicate. Updates of base tables are specified by update tables, which are derived tables defined by rules, as discussed previously.
Bottom-up logic programming can support
recursive rules at the cost of a significantly more
complicated algorithm (a fixed-point iteration [
Alternatively, TED programs can be executed in parallel. Each predicate is updated in a separate task. Once a table is updated, all further access are readonly, so parallel update requires no locking or other mutual exclusion. The “continuation” feature of the C# task parallelism library is sufficient to guarantee tasks are not scheduled until the tasks they depend on have been completed, so there is no explicit blocking.
Since each predicate is updated by a single task, the level of parallelism depends on the number of predicates in the program and the length of their serial dependencies.
TED is currently used in two projects. It is being used
for consistency-checking the asset database of an
unannounced commercial game. It was chosen over
Unity Prolog [
The main project using TED is Voix de la Ville, a
declarative reimplementation of a subset of Ryan’s
Talk of the Town city simulator [
Many AI-based games have used symbolic rules for
character control. MKULTRA [
Several game development frameworks and social
simulation middleware have used symbolic rules,
particular for interactive narrative. One of the earliest
and most influential such systems is the Nelson’s
Inform 7 language [
Several systems have used forward-chaining
rulebased systems, including ABL, Comme Il Faut [
To our knowledge, bottom-up logic programming
has not previously been used to implement social
simulations. However, Datalog has been used for
storysifting [
Bottom-up logic programming, and Datalog in
particular, has received the most attention in the
database community [
Games involving large-scale social simulation are
relatively rare. The best known is Dwarf Fortress [
Kismet [
TED is a high-performance, embedded, parallelizable, logic programming system that allows game designers to quickly and conveniently implement large-scale social simulations and run them quickly on modern, multi-core architectures. It allows story-sifting and simulation to be written in the same language. The use of tables to store all intermediate results aids debugging by making all intermediate results inspectable and queryable at run-time.