Functional Programming in Lua

What is Functional Programming in Lua?

Functional programming is a paradigm that treats computation as the evaluation of mathematical functions, avoiding mutable state and side effects. In Lua, while the language is not purely functional, it offers powerful first-class functions, closures, and tail-call elimination that make a functional style both possible and elegant. You can write code that emphasises what to solve rather than how, leading to cleaner, more predictable, and more testable programs.

Why Functional Programming Matters in Lua

Adopting a functional mindset in Lua brings several concrete benefits, even in an otherwise imperative codebase:

• Modularity: Small, composable functions are easier to reuse and combine.
• Predictability: Pure functions always produce the same output for the same input, making debugging simpler.
• Concurrency readiness: Immutable data and no shared state reduce bugs when dealing with coroutines or multi‑threaded environments (e.g., Lua‑based game engines).
• Expressive power: Higher‑order functions let you abstract control flows like iteration and branching without repetitive boilerplate.
• Tail‑call optimisation: Lua’s proper tail calls allow recursive algorithms to run in constant stack space, enabling efficient functional loops.

Core Concepts and How to Use Them

First‑Class Functions and Higher‑Order Functions

In Lua, functions are values that can be assigned to variables, passed as arguments, and returned from other functions. A higher‑order function is simply one that takes or returns a function.

-- Assign a function to a variable
local greet = function(name)
  return "Hello, " .. name
end

-- A higher‑order function that applies a function twice
local function twice(f, x)
  return f(f(x))
end

print(twice(greet, "Lua"))   -- "Hello, Hello, Lua"

This trivial example already shows how behaviour can be passed around and modified at runtime.

Pure Functions and Immutability

A pure function depends only on its explicit inputs and produces no side effects (no mutation of external state, no I/O). In Lua, tables are mutable by default, but you can adopt a convention of returning new tables instead of modifying existing ones.

-- Pure function: returns a new table, leaves original untouched
local function append_copy(tbl, value)
  local new = {}
  for i, v in ipairs(tbl) do
    new[i] = v
  end
  new[#new + 1] = value
  return new
end

local original = {1, 2, 3}
local modified = append_copy(original, 4)

print(original[4])   -- nil (unchanged)
print(modified[4])   -- 4

By favouring such “copy‑on‑write” patterns, you drastically reduce hidden dependencies and make your code easier to reason about.

Function Composition

Composition is the act of combining simple functions to build more complex ones. You can write a generic compose utility that takes two functions and returns their pipeline.

local function compose(f, g)
  return function(x)
    return f(g(x))
  end
end

local add_one = function(x) return x + 1 end
local double = function(x) return x * 2 end

local add_one_then_double = compose(double, add_one)
local double_then_add_one = compose(add_one, double)

print(add_one_then_double(3))   -- 8
print(double_then_add_one(3))   -- 7

Composition works beautifully with partial application and currying, which we’ll explore next.

Closures and Partial Application

Lua’s closures capture variables from their enclosing scope. This enables partial application – fixing some arguments of a function to create a new, more specialised function.

-- Generic partial application helper
local function partial(f, ...)
  local bound_args = {...}
  return function(...)
    return f(table.unpack(bound_args), ...)
  end
end

local function multiply(a, b)
  return a * b
end

local double = partial(multiply, 2)
local triple = partial(multiply, 3)

print(double(5))   -- 10
print(triple(5))   -- 15

Closures are also the backbone of data hiding and state encapsulation, but in pure functional code they are used primarily to remember bound arguments without side effects.

Recursion

Recursion replaces loops in many functional patterns. Lua guarantees proper tail‑call elimination, meaning a recursive call in tail position doesn’t grow the call stack.

-- Tail‑recursive factorial
local function fact(n, acc)
  acc = acc or 1
  if n == 0 then return acc end
  return fact(n - 1, acc * n)   -- tail call
end

print(fact(10000))   -- works without stack overflow (prints huge number)

Always structure recursive functions so the last action is the recursive call itself (or a returned value). This allows Lua to reuse the current stack frame, making deep recursion safe.

Lazy Evaluation with Iterators

Lua iterators are a form of lazy evaluation. Functions like string.gmatch or custom iterator factories produce values on demand, which fits the functional style of processing sequences without building intermediate lists.

-- A lazy infinite sequence of natural numbers (truncated for display)
local function naturals()
  local i = 0
  return function()
    i = i + 1
    return i
  end
end

local function take(n, iterator)
  local results = {}
  for _, v in iterator, nil, n do   -- generic for stops after n iterations
    results[#results + 1] = v
  end
  return results
end

local first_five = take(5, naturals())
print(table.concat(first_five, ", "))   -- 1, 2, 3, 4, 5

By combining iterator factories with transformation functions, you can process large or even infinite streams of data without eagerly materialising them.

Practical Examples: Building Functional Utilities

Map, Filter, Reduce

These three functions are the bread and butter of functional data transformation. Here is how you can implement them for Lua tables (arrays):

-- map: transforms each element
local function map(tbl, fn)
  local result = {}
  for i, v in ipairs(tbl) do
    result[i] = fn(v)
  end
  return result
end

-- filter: keeps elements where predicate is truthy
local function filter(tbl, predicate)
  local result = {}
  for _, v in ipairs(tbl) do
    if predicate(v) then
      result[#result + 1] = v
    end
  end
  return result
end

-- reduce: folds a value across the table
local function reduce(tbl, fn, initial)
  local acc = initial
  for _, v in ipairs(tbl) do
    acc = fn(acc, v)
  end
  return acc
end

local numbers = {1, 2, 3, 4, 5}

-- Example pipeline: double even numbers, then sum them
local doubled_evens = map(filter(numbers, function(x) return x % 2 == 0 end),
                          function(x) return x * 2 end)
local sum = reduce(doubled_evens, function(a, b) return a + b end, 0)

print(sum)   -- 12 (2*2 + 4*2)

These functions are pure (they return new tables) and composable, allowing you to build complex transformations step by step.

Currying

Currying transforms a function that takes multiple arguments into a chain of single‑argument functions. This is especially useful for composition and partial application.

-- Manual currying for a 3‑argument function
local function curry3(f)
  return function(a)
    return function(b)
      return function(c)
        return f(a, b, c)
      end
    end
  end
end

local function sum3(x, y, z) return x + y + z end
local curried_sum = curry3(sum3)

-- You can partially apply step by step
local add5 = curried_sum(5)
local add5and2 = add5(2)      -- equivalent to sum3(5,2,z)
print(add5and2(3))            -- 10

-- Generic curry helper using varargs (simplified)
local function curry(f, n)
  n = n or debug.getinfo(f, "u").nparams   -- approximate arity
  local function curried(...)
    local args = {...}
    if #args >= n then
      return f(table.unpack(args))
    else
      return function(...)
        return curried(table.unpack(args), ...)
      end
    end
  end
  return curried
end

local curried_multiply = curry(function(a, b, c) return a * b * c end, 3)
print(curried_multiply(2)(3)(4))   -- 24

Currying shines when you want to configure a function gradually before final invocation, often in pipelines.

Composing Pipelines

Using composition, currying, and map/filter/reduce, you can build expressive data processing pipelines that read almost like a specification.

-- A simple pipeline utility that composes a list of functions left-to-right
local function pipeline(...)
  local funcs = {...}
  return function(x)
    local val = x
    for _, f in ipairs(funcs) do
      val = f(val)
    end
    return val
  end
end

local function trim(s) return s:match("^%s*(.-)%s*$") end
local function uppercase(s) return s:upper() end
local function exclaim(s) return s .. "!" end

local process = pipeline(trim, uppercase, exclaim)
print(process("  hello world  "))   -- "HELLO WORLD!"

-- Pipeline for table transformation
local numbers = {1, 2, 3, 4, 5, 6}
local keep_odd = function(t) return filter(t, function(x) return x % 2 ~= 0 end) end
local square_all = function(t) return map(t, function(x) return x * x end) end

local transform = pipeline(keep_odd, square_all, function(t) return reduce(t, function(a,b) return a+b end, 0) end)
print(transform(numbers))   -- 1² + 3² + 5² = 1+9+25 = 35

Notice how each step is a pure, reusable function. The pipeline itself is a higher‑order function that builds new behaviour by combining them.

Best Practices and Caveats

Leverage Tail‑Call Optimisation

Lua’s tail‑call elimination is one of its most under‑appreciated features. Always put recursive calls in tail position (the last thing before return) and avoid wrapping them in extra logic. For example, return fact(n-1, acc*n) is a tail call; return 1 + fact(n-1) is not. Use accumulators to convert non‑tail‑recursive functions into tail‑recursive ones.

Prefer Immutable Tables Where Possible

While deep copying tables can be expensive, for small to medium‑sized data structures the clarity gain is worth it. Consider libraries like luafun or underscore-lua if you need optimised functional operations. Always document whether a function mutates its arguments or returns a new value – a naming convention like with_ prefix helps.

Keep Functions Pure and Small

A pure function should be short, focused, and free of side effects. Avoid accessing global state or performing I/O inside functions that are meant to be combinable. If you must interact with the world (e.g., logging), push that to the outermost layer of your program.

Be Mindful of Performance

Functional patterns create many intermediate tables. In performance‑critical sections (like game update loops), you might want to reuse tables or fall back to imperative loops. Use profiling to decide. LuaJIT’s tracing JIT often optimises closures and function calls aggressively, but table allocations still have a cost. Strike a balance: functional for clarity, imperative where necessary.

Use Iterators Instead of Building Huge Lists

When processing large datasets, prefer lazy iterator pipelines (like luafun provides) over eagerly building intermediate tables. This keeps memory usage low and fits the functional “pull‑based” model naturally.

Conclusion

Functional programming in Lua is not just a theoretical exercise – it’s a practical tool that helps you write cleaner, more modular code. By embracing first‑class functions, pure transformations, composition, and recursion with tail‑call optimisation, you can create programs that are easier to test, debug, and extend. The techniques covered here – map, filter, reduce, currying, and pipelines – give you a solid foundation for tackling real‑world problems with a functional flair. As with any paradigm, the key is to use it where it shines, blending it gracefully with Lua’s imperative strengths to build robust, maintainable software.