Interpreter Pattern in C#: When and How to Build a DSL

The marketing team wants to author discount rules without filing a ticket. "20% off if cart contains BOOK and total over 50". "Free shipping for orders weighing under 2 kg in the US". By next quarter they expect twenty rules, by next year a hundred. Hard-coding each rule in C# means every rule needs a deployment.

The Interpreter pattern is one answer. Define a small grammar for the rule language, parse rule strings into an abstract syntax tree, and have each node implement Evaluate(context). The Interpreter is the rarest GoF pattern in real .NET applications, because Expression trees, Roslyn scripting, and existing rule engines cover most cases. But understanding it tells you what those tools do under the hood — and when to actually reach for it.

What problem does the Interpreter pattern solve in C#?

The pattern earns its place when non-developers must author behaviour at runtime, in a language smaller than C#. Three concrete shapes:

1. Business rule DSL. Discount rules, validation rules, eligibility rules. Edited by analysts, deployed without a build.
2. Query languages. A search box that accepts tag:book price<50 author:rowling. Each token becomes an AST node; the evaluator filters the data store.
3. Configuration with logic. A YAML file that says enable: when env=prod and rollout>50%. Avoids "config that is really code" anti-patterns by giving the config a declared, bounded grammar.

What is not an Interpreter problem: "I want to dispatch one of a few methods at runtime" — that is Strategy or Command. "I want users to write C#" — use Roslyn scripting; the pattern is overkill.

How does the textbook Interpreter look?

A class per grammar construct, each with an Evaluate(context) that returns a value:

public sealed record CartContext(string[] Skus, decimal Total, double WeightKg, string Country);

public interface IRule { bool Eval(CartContext ctx); }

public sealed class ContainsSku(string Sku) : IRule
{
    public bool Eval(CartContext ctx) => ctx.Skus.Contains(Sku);
}

public sealed class TotalGreaterThan(decimal Threshold) : IRule
{
    public bool Eval(CartContext ctx) => ctx.Total > Threshold;
}

public sealed class And(IRule Left, IRule Right) : IRule
{
    public bool Eval(CartContext ctx) => Left.Eval(ctx) && Right.Eval(ctx);
}

public sealed class Or(IRule Left, IRule Right) : IRule
{
    public bool Eval(CartContext ctx) => Left.Eval(ctx) || Right.Eval(ctx);
}

The user-typed rule "cart contains BOOK and total over 50" parses into an And whose left child is a ContainsSku("BOOK") and right child is a TotalGreaterThan(50m). Calling .Eval(ctx) walks the tree.

The structural picture (the tree, not a class hierarchy):

flowchart TB
    And[And]
    And --> Contains[ContainsSku 'BOOK']
    And --> Total[TotalGreaterThan 50]

Add a new operator (Not, WeightUnder) by writing one new class. The interpreter does not know about specific rules; the rules do not know about each other.

How do Expression trees give you the same pattern for free?

System.Linq.Expressions is the BCL implementation of Interpreter. You build the AST by composing typed expression objects, then either walk it (LINQ-to-Entities translates to SQL) or compile it to a delegate:

using System.Linq.Expressions;

ParameterExpression ctx = Expression.Parameter(typeof(CartContext), "c");

Expression contains = Expression.Call(
    Expression.Property(ctx, nameof(CartContext.Skus)),
    typeof(Enumerable).GetMethod(nameof(Enumerable.Contains), new[] { typeof(string[]), typeof(string) })!,
    Expression.Constant("BOOK"));

Expression total = Expression.GreaterThan(
    Expression.Property(ctx, nameof(CartContext.Total)),
    Expression.Constant(50m));

Expression body = Expression.AndAlso(contains, total);

var lambda = Expression.Lambda<Func<CartContext, bool>>(body, ctx);
Func<CartContext, bool> rule = lambda.Compile();

rule(myCart) returns true or false. EF Core takes a similar tree and turns it into a SQL WHERE clause. The Interpreter pattern is hidden inside the BCL classes; you never write class And : IRule yourself.

For most application-internal rule logic, this is the right answer. Hand-written interpreters earn their keep when the user writes the rules — and writes them in a string the application has to parse.

How do you build a tiny DSL parser in .NET 10?

The minimum-viable parser for the rule language above:

public static class RuleParser
{
    public static IRule Parse(string source)
    {
        var tokens = source.Split(' ', StringSplitOptions.RemoveEmptyEntries);
        return ParseAnd(tokens, 0, out _);
    }

    private static IRule ParseAnd(string[] tokens, int i, out int next)
    {
        var left = ParseAtom(tokens, i, out i);
        while (i < tokens.Length && tokens[i].Equals("and", StringComparison.OrdinalIgnoreCase))
        {
            var right = ParseAtom(tokens, i + 1, out i);
            left = new And(left, right);
        }
        next = i;
        return left;
    }

    private static IRule ParseAtom(string[] tokens, int i, out int next)
    {
        if (tokens[i].Equals("contains", StringComparison.OrdinalIgnoreCase))
        {
            next = i + 2;
            return new ContainsSku(tokens[i + 1]);
        }
        if (tokens[i].Equals("total>", StringComparison.OrdinalIgnoreCase))
        {
            next = i + 2;
            return new TotalGreaterThan(decimal.Parse(tokens[i + 1]));
        }
        throw new InvalidOperationException($"Unknown token: {tokens[i]}");
    }
}

// Usage
IRule rule = RuleParser.Parse("contains BOOK and total> 50");
bool applies = rule.Eval(new CartContext(new[] {"BOOK", "MUG"}, 75m, 1.0, "US"));

This is the whole Interpreter pattern compressed into 30 lines: a grammar, a parser, an AST, a walker. For a real rule engine you would replace the recursive-descent parser with a generated one (Sprache, Pidgin, Superpower) and add operator precedence — but the shape stays the same.

When does the Interpreter pattern misfire?

Three traps:

• Premature DSL. Three rules and a switch is simpler than a parser. Build the DSL when the rule count crosses the threshold where the cost of a deploy per rule exceeds the cost of writing a parser. That threshold is usually higher than engineers think.
• Insecure runtime input. A rule string from an admin UI is user input. If your interpreter calls Eval() on arbitrary reflection, you have just exposed a sandbox escape. Define a closed grammar; reject anything outside it.
• Reinventing Expression trees. If your AST is "binary op, comparison, member access, constant", the BCL has done this. Use Expression<> and Compile(); do not write class And from scratch.

How does Interpreter compare to Strategy and Visitor?

The cleanest split: Interpreter is for parsing and evaluating text; Visitor is for adding operations to an existing tree; Strategy is for swapping a single algorithm. Visitor and Interpreter often pair: build the AST with Interpreter, walk it with Visitor.

What does a real .NET 10 example look like?

For ninety per cent of cases, the real .NET 10 example uses Expression trees rather than a hand-written interpreter. Here is the discount-rule scenario solved that way:

public sealed record CartContext(string[] Skus, decimal Total, double WeightKg, string Country);

public sealed class CompiledRule
{
    public CompiledRule(string source, Expression<Func<CartContext, bool>> expr)
    {
        Source   = source;
        Compiled = expr.Compile();
    }
    public string Source { get; }
    public Func<CartContext, bool> Compiled { get; }
    public bool Applies(CartContext ctx) => Compiled(ctx);
}

public sealed class DiscountRuleEngine
{
    private readonly List<CompiledRule> _rules = new();

    public void Add(string source, Expression<Func<CartContext, bool>> expr)
        => _rules.Add(new CompiledRule(source, expr));

    public IEnumerable<string> Matching(CartContext ctx)
        => _rules.Where(r => r.Applies(ctx)).Select(r => r.Source);
}

// Caller (rules expressed in C# at startup)
var engine = new DiscountRuleEngine();
engine.Add("books over 50",
    c => c.Skus.Contains("BOOK") && c.Total > 50m);
engine.Add("light orders to US",
    c => c.WeightKg < 2.0 && c.Country == "US");

var ctx = new CartContext(new[] { "BOOK", "MUG" }, 75m, 1.0, "US");
foreach (var match in engine.Matching(ctx))
    Console.WriteLine($"matched: {match}");

If marketing must author rules in their own string format, layer the RuleParser from the previous section on top to translate text into either an IRule AST or an Expression<Func<>>. The evaluation uses the BCL's interpreter; only the parser is yours.

Where should you read next in this series?

• Previous: Command — encapsulating an action as a record + handler.
• Next: Iterator — uniform traversal through IEnumerable<T> and yield return.
• Cross-reference: Visitor — adding operations to a fixed AST.
• Cross-reference: Strategy — when the choice is "which algorithm" rather than "what does this expression mean".
• Decision tree: How to choose the right design pattern.

A pragmatic ending: most C# developers will never write a hand-rolled Interpreter, and that is fine. What matters is recognising the pattern when you see it in EF Core, in Expression<>, in your favourite rule engine — and recognising when not to build your own. The framework usually wins.