DOMAIN SPECIFIC LANGUAGES DSL PROJECTS

Domain-Specific Languages (DSLs) - Project-Based Learning Path

Goal: Understand how to design, build, and use Domain-Specific Languages from simple internal DSLs to full external languages with custom parsers.

What You’ll Master

By completing these projects, you’ll understand:

How to design languages for specific problem domains
Lexing, parsing, and AST construction
Internal DSLs using fluent APIs and method chaining
Macro-based metaprogramming for compile-time DSLs
Parser combinators and parser generators
Code generation and interpretation
When to use DSLs vs. general-purpose code

Project Comparison Table

Project	Difficulty	Time	Depth of Understanding	Fun Factor	Business Potential
Fluent Query Builder	Beginner	Weekend	⭐⭐	⭐⭐⭐	Micro-SaaS
Config File Parser	Beginner-Intermediate	Weekend	⭐⭐⭐	⭐⭐	Service & Support
Filter Expression Language	Intermediate	1-2 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐	Open Core
Product Catalog Rules DSL	Intermediate-Advanced	2-3 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	Service & Support
Macro-Based HTML DSL	Advanced	1-2 weeks	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Resume Gold
Template Engine	Advanced	2-3 weeks	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	Open Core
Final: Business Rules Engine	Expert	1 month+	⭐⭐⭐⭐⭐	⭐⭐⭐⭐⭐	Industry Disruptor

Project 1: Fluent Query Builder (Internal DSL)

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: Python
Alternative Programming Languages: Ruby, Kotlin, TypeScript
Coolness Level: Level 2: Practical but Forgettable
Business Potential: 2. The “Micro-SaaS / Pro Tool”
Difficulty: Level 1: Beginner
Knowledge Area: API Design / Fluent Interfaces
Software or Tool: ORM-like Query Builder
Main Book: “Domain Specific Languages” by Martin Fowler

What you’ll build: A chainable API for building database queries that reads like English: query.select("name", "email").from("users").where("age > 18").order_by("name").limit(10)

Why it teaches DSLs: This is the gentlest introduction to DSL thinking. You’ll learn that a DSL doesn’t require parsing—it can be embedded directly in your host language using method chaining. Every method returns self, enabling the fluent pattern.

Core challenges you’ll face:

Method chaining design (each method returns self) → maps to fluent interface pattern
State accumulation (tracking what’s been configured) → maps to builder pattern
Type safety (preventing invalid combinations) → maps to DSL constraints
SQL generation (converting builder state to string) → maps to code generation basics

Key Concepts:

Fluent Interface Pattern: “Domain Specific Languages” Chapter 35 - Martin Fowler
Builder Pattern: “Design Patterns” Chapter 3 - Gang of Four
Method Chaining: “Clean Code” Chapter 3 (Functions) - Robert C. Martin

Difficulty: Beginner Time estimate: Weekend Prerequisites: Basic Python, understanding of classes

Real world outcome:

# Your DSL in action
query = (Query()
    .select("name", "email", "created_at")
    .from_table("users")
    .where("age > 21")
    .where("status = 'active'")
    .order_by("created_at", "DESC")
    .limit(50))

print(query.to_sql())
# Output: SELECT name, email, created_at FROM users WHERE age > 21 AND status = 'active' ORDER BY created_at DESC LIMIT 50

# Execute against real SQLite database
results = query.execute(db_connection)
for row in results:
    print(f"{row['name']}: {row['email']}")

Learning milestones:

Basic chaining works → You understand fluent interfaces
Multiple where clauses combine correctly → You understand state accumulation
Invalid queries raise helpful errors → You understand DSL validation
Generated SQL is correct and safe → You understand code generation

Project 2: Configuration File Parser (External DSL - Simple)

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: C
Alternative Programming Languages: Rust, Go, Python
Coolness Level: Level 3: Genuinely Clever
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 2: Intermediate
Knowledge Area: Parsing / Lexical Analysis
Software or Tool: Config Parser (like TOML/INI)
Main Book: “Crafting Interpreters” by Robert Nystrom (free online)

What you’ll build: A parser for a simple configuration format that supports sections, key-value pairs, comments, and basic types (strings, numbers, booleans, arrays).

# Server configuration
[server]
host = "localhost"
port = 8080
debug = true

[database]
connection_string = "postgres://localhost/mydb"
max_connections = 10
allowed_origins = ["http://localhost", "https://example.com"]

Why it teaches DSLs: This is your first “real” external DSL. You’ll implement the fundamental pipeline: Source Text → Lexer → Tokens → Parser → Data Structure. This exact pattern scales to any language.

Core challenges you’ll face:

Tokenization (breaking text into meaningful chunks) → maps to lexical analysis
Handling whitespace and comments (ignoring irrelevant text) → maps to token filtering
Nested structures (arrays, sections) → maps to recursive descent parsing
Error messages (line numbers, helpful context) → maps to error recovery
Type coercion (strings to numbers/booleans) → maps to semantic analysis

Key Concepts:

Lexical Analysis: “Crafting Interpreters” Chapter 4 - Robert Nystrom
Recursive Descent Parsing: “Crafting Interpreters” Chapter 6 - Robert Nystrom
Finite State Machines for Lexing: “Engineering a Compiler” Chapter 2 - Cooper & Torczon
Error Handling in Parsers: “Language Implementation Patterns” Chapter 4 - Terence Parr

Resources for key challenges:

Crafting Interpreters - Scanning - The best free intro to building a lexer
TOML Specification - See how a real config language is specified

Difficulty: Beginner-Intermediate Time estimate: Weekend Prerequisites: String manipulation, basic data structures

Real world outcome:

$ cat myapp.conf
[server]
host = "0.0.0.0"
port = 3000
debug = true

[features]
enabled = ["auth", "logging", "metrics"]

$ ./config_parser myapp.conf
Parsed configuration:
  [server]
    host: "0.0.0.0" (string)
    port: 3000 (integer)
    debug: true (boolean)
  [features]
    enabled: ["auth", "logging", "metrics"] (array of 3 strings)

$ ./config_parser broken.conf
Error at line 5: Expected '=' after key 'port', found 'EOF'

Learning milestones:

Lexer produces correct tokens → You understand tokenization
Parser handles nested arrays → You understand recursive structures
Error messages show line numbers → You understand error tracking
Round-trip works (parse → serialize → parse) → You have a complete implementation

Project 3: Filter Expression Language

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: Python
Alternative Programming Languages: TypeScript, Rust, Go
Coolness Level: Level 3: Genuinely Clever
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 2: Intermediate
Knowledge Area: Parsing / Expression Evaluation
Software or Tool: Query Language (like MongoDB queries)
Main Book: “Language Implementation Patterns” by Terence Parr

What you’ll build: A mini query language for filtering collections, similar to MongoDB queries or Elasticsearch Query DSL:

name == "John" AND (age >= 21 OR status == "verified") AND tags CONTAINS "premium"

This filter expression gets parsed into an AST, then evaluated against data.

Why it teaches DSLs: This project introduces operator precedence, boolean logic, and AST evaluation—the core of any expression-based language. You’ll build something actually useful: a filter that can be stored in a database and evaluated at runtime.

Core challenges you’ll face:

Operator precedence (AND binds tighter than OR) → maps to grammar design
Parentheses for grouping (overriding precedence) → maps to recursive parsing
AST construction (building a tree from flat tokens) → maps to parse tree design
Tree evaluation (walking the AST to compute result) → maps to interpreter pattern
Multiple operators (==, !=, >, <, CONTAINS, IN) → maps to extensible grammars

Key Concepts:

Abstract Syntax Trees: “Crafting Interpreters” Chapter 5 - Robert Nystrom
Operator Precedence Parsing: “Language Implementation Patterns” Chapter 5 - Terence Parr
Tree-Walking Interpreters: “Crafting Interpreters” Chapter 7 - Robert Nystrom
Visitor Pattern for ASTs: “Design Patterns” Chapter 5 - Gang of Four

Resources for key challenges:

Pratt Parsing - Elegant algorithm for operator precedence
A custom DSL for Rules Engine using Lark - Practical Python example

Difficulty: Intermediate Time estimate: 1-2 weeks Prerequisites: Recursion, tree data structures, Project 2 concepts

Real world outcome:

# Define your filter DSL
filter_expr = 'status == "active" AND (role == "admin" OR permissions CONTAINS "write")'

# Parse it into an AST
ast = parse_filter(filter_expr)
print(ast.pretty())
# Output:
# AND
#   EQUALS(status, "active")
#   OR
#     EQUALS(role, "admin")
#     CONTAINS(permissions, "write")

# Evaluate against data
users = [
    {"name": "Alice", "status": "active", "role": "admin", "permissions": ["read"]},
    {"name": "Bob", "status": "active", "role": "user", "permissions": ["read", "write"]},
    {"name": "Charlie", "status": "inactive", "role": "admin", "permissions": ["read"]},
]

results = [u for u in users if evaluate(ast, u)]
# Results: [Alice, Bob] - Charlie is excluded (inactive)

# Store filter in database, load later, still works!
saved_filter = save_to_db(filter_expr)
loaded_ast = parse_filter(load_from_db(saved_filter))

Learning milestones:

Simple comparisons parse and evaluate → You understand basic parsing
AND/OR with correct precedence → You understand operator precedence
Parentheses override precedence → You understand recursive grouping
Invalid expressions give helpful errors → You understand error handling

Project 4: Product Catalog Rules DSL

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: Python
Alternative Programming Languages: Ruby, Elixir, TypeScript
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 3. The “Service & Support” Model
Difficulty: Level 3: Advanced
Knowledge Area: Business Rules / Constraint Systems
Software or Tool: Product Rules Engine
Main Book: “Domain Specific Languages” by Martin Fowler

What you’ll build: A DSL specifically designed for your use case—defining product relationships, bundles, constraints, and pricing rules:

# Product definitions
PRODUCT laptop "MacBook Pro 16" {
    category: electronics
    base_price: 2499.00
    attributes: [color, memory, storage]
}

PRODUCT case "Laptop Sleeve" {
    category: accessories
    base_price: 49.00
}

# Bundle rules
BUNDLE "Work From Home Kit" {
    includes: [laptop, case, keyboard, mouse]
    discount: 15%
    constraint: laptop.memory >= 16GB
}

# Compatibility rules
RULE laptop_case_compatibility {
    when: cart CONTAINS laptop
    suggest: case WITH message "Protect your investment!"
    discount: case BY 20% IF purchased_together
}

# Constraint rules
RULE storage_memory_constraint {
    when: laptop.storage == "2TB"
    require: laptop.memory >= 32GB
    error: "2TB storage requires at least 32GB memory"
}

# Pricing rules
RULE bulk_discount {
    when: cart.quantity(category: accessories) >= 3
    apply: 10% OFF category: accessories
}

Why it teaches DSLs: This is where DSL design becomes real business value. You’ll create a language that non-programmers can read and modify. The challenge is designing syntax that’s both expressive and unambiguous.

Core challenges you’ll face:

Domain modeling (what concepts exist? how do they relate?) → maps to language design
Rule evaluation order (which rules fire first?) → maps to execution semantics
Constraint propagation (if A requires B, and B requires C…) → maps to inference engines
Conflict resolution (two rules contradict each other) → maps to rule priority systems
User-friendly errors (business users need to understand what’s wrong) → maps to error UX

Key Concepts:

Semantic Model Design: “Domain Specific Languages” Chapters 11-12 - Martin Fowler
Rule-Based Systems: “Artificial Intelligence: A Modern Approach” Chapter 7 - Russell & Norvig
Forward Chaining: Martin Fowler’s Rules Engine - When to use rules
Grammar Design: “Language Implementation Patterns” Chapter 5 - Terence Parr

Resources for key challenges:

A DSL rule engine - RedBus - Real-world implementation story
business-rule-engine (Python) - Reference implementation

Difficulty: Intermediate-Advanced Time estimate: 2-3 weeks Prerequisites: Projects 2-3 concepts, understanding of business rules

Real world outcome:

$ cat products.rules
PRODUCT laptop "MacBook Pro" { base_price: 2499.00 }
PRODUCT case "Sleeve" { base_price: 49.00 }

BUNDLE "Developer Kit" {
    includes: [laptop, case]
    discount: 10%
}

RULE suggest_case {
    when: cart CONTAINS laptop AND NOT cart CONTAINS case
    suggest: case WITH message "Don't forget protection!"
}

$ ./catalog_engine products.rules --interactive
> add laptop
Added: MacBook Pro ($2499.00)
💡 Suggestion: Don't forget protection! Add "Sleeve" for $49.00

> add case
Added: Sleeve ($49.00)
🎁 Bundle detected: "Developer Kit" - Save 10%!

> cart
Your Cart:
  - MacBook Pro: $2499.00
  - Sleeve: $49.00
  Subtotal: $2548.00
  Bundle Discount (Developer Kit): -$254.80
  ─────────────────
  Total: $2293.20

> validate
✓ All constraints satisfied
✓ No conflicting rules

Learning milestones:

Products and bundles parse correctly → You understand domain-specific syntax
Rules trigger on cart changes → You understand event-driven evaluation
Constraint violations show clear errors → You understand validation design
Complex rule interactions work correctly → You understand rule engines

Project 5: Macro-Based HTML DSL (Compile-Time DSL)

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: Elixir
Alternative Programming Languages: Rust (proc macros), Lisp/Clojure, Nim
Coolness Level: Level 5: Pure Magic
Business Potential: 1. The “Resume Gold”
Difficulty: Level 4: Expert
Knowledge Area: Metaprogramming / Macros
Software or Tool: HTML Template DSL
Main Book: “Metaprogramming Elixir” by Chris McCord

What you’ll build: A macro-based DSL that generates HTML at compile time, similar to Phoenix’s HEEx or React’s JSX:

defmodule MyPage do
  use HtmlDsl

  def render(user) do
    html do
      head do
        title "Welcome, #{user.name}!"
      end
      body class: "dark-mode" do
        div id: "main" do
          h1 "Hello, #{user.name}!"

          if user.admin? do
            div class: "admin-panel" do
              a href: "/admin", "Admin Dashboard"
            end
          end

          ul do
            for item <- user.items do
              li item.name
            end
          end
        end
      end
    end
  end
end

Why it teaches DSLs: Macros transform code at compile time, meaning your DSL has zero runtime overhead. You’ll learn how Elixir’s quote and unquote work, how the AST is represented, and how to manipulate code as data.

Core challenges you’ll face:

Understanding AST representation (code is data in Elixir) → maps to homoiconicity
Quoting and unquoting (capturing vs. injecting code) → maps to macro hygiene
Recursive macro expansion (nested tags) → maps to macro composition
Compile-time validation (catch errors before runtime) → maps to static analysis
Integration with host language (using if, for inside DSL) → maps to seamless embedding

Key Concepts:

Quote and Unquote: “Metaprogramming Elixir” Chapter 1 - Chris McCord
Macro Expansion: Elixir School - Metaprogramming
AST Manipulation: “Metaprogramming Elixir” Chapter 2 - Chris McCord
Compile-Time Checks: Elixir Macros Demystified

Resources for key challenges:

Elixir: Basics of Metaprogramming - Excellent 2024 tutorial
Understanding Elixir Macros - In-depth explanation

Difficulty: Advanced Time estimate: 1-2 weeks Prerequisites: Elixir basics, understanding of compile vs. runtime

Real world outcome:

# Your DSL in action
iex> MyPage.render(%User{name: "Alice", admin?: true, items: [%{name: "Book"}, %{name: "Pen"}]})

"<html><head><title>Welcome, Alice!</title></head><body class=\"dark-mode\"><div id=\"main\"><h1>Hello, Alice!</h1><div class=\"admin-panel\"><a href=\"/admin\">Admin Dashboard</a></div><ul><li>Book</li><li>Pen</li></ul></div></body></html>"

# Compile-time error checking
iex> html do
...>   div clas: "typo" do  # Note: 'clas' instead of 'class'
...>   end
...> end

** (CompileError) unknown attribute 'clas'. Did you mean 'class'?

Learning milestones:

Simple tags generate correct HTML → You understand basic macros
Nested tags work recursively → You understand macro composition
Attributes render correctly → You understand keyword arguments in AST
Host language constructs (if/for) work inside DSL → You’ve mastered integration

Project 6: Template Engine with Custom Syntax

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: Rust
Alternative Programming Languages: Go, C, Zig
Coolness Level: Level 4: Hardcore Tech Flex
Business Potential: 4. The “Open Core” Infrastructure
Difficulty: Level 4: Expert
Knowledge Area: Parsing / Code Generation
Software or Tool: Template Engine (like Jinja2/Handlebars)
Main Book: “Crafting Interpreters” by Robert Nystrom

What you’ll build: A full template engine with custom syntax, variable interpolation, control flow, and includes:

{# This is a comment #}
<html>
<head><title>{{ page.title }}</title></head>
<body>
  <h1>Hello, {{ user.name | uppercase }}!</h1>

  {% if user.is_authenticated %}
    <nav>
      {% for item in menu_items %}
        <a href="{{ item.url }}"
           {% if item.active %}class="active"{% endif %}>
          {{ item.label }}
        </a>
      {% endfor %}
    </nav>
  {% else %}
    <a href="/login">Sign In</a>
  {% endif %}

  {% include "footer.html" %}
</body>
</html>

Why it teaches DSLs: This combines everything: lexing, parsing, AST construction, and code generation. Template engines are one of the most practical DSLs you can build—every web framework has one.

Core challenges you’ll face:

Mixed-mode lexing (switching between text and code) → maps to lexer states/modes
Expression parsing (variable access, filters, function calls) → maps to expression grammars
Control flow compilation (if/for become code) → maps to bytecode/IR generation
Filter/pipe system (value | filter1 | filter2) → maps to function composition
Template inheritance (extends, blocks) → maps to symbol tables and scoping

Key Concepts:

Lexer Modes: “Crafting Interpreters” Chapter 4 (extended) - Robert Nystrom
Expression Parsing: “Language Implementation Patterns” Chapter 5 - Terence Parr
Bytecode Compilation: “Crafting Interpreters” Chapters 14-15 - Robert Nystrom
Template Compilation: Study Jinja2’s Template Designer Documentation

Resources for key challenges:

Building a DSL with Rust - Rust-specific guidance
nom or pest - Rust parser libraries

Difficulty: Advanced Time estimate: 2-3 weeks Prerequisites: Strong parsing skills, Projects 2-3, systems programming basics

Real world outcome:

$ cat template.html
<h1>{{ title }}</h1>
{% for item in items %}
  <p>{{ item | capitalize }}</p>
{% endfor %}

$ cat data.json
{"title": "My List", "items": ["apple", "banana", "cherry"]}

$ ./template_engine template.html data.json
<h1>My List</h1>
  <p>Apple</p>
  <p>Banana</p>
  <p>Cherry</p>

# Performance mode - compile to bytecode
$ ./template_engine --compile template.html -o template.tplc
Compiled: template.html -> template.tplc (47 instructions)

$ ./template_engine --run template.tplc data.json
<h1>My List</h1>
...

Learning milestones:

Variable interpolation works → You understand basic expression evaluation
Control flow (if/for) works → You understand compiling control structures
Filters chain correctly → You understand function composition
Compiled templates run fast → You understand bytecode benefits

Final Project: Complete Business Rules Engine

File: DOMAIN_SPECIFIC_LANGUAGES_DSL_PROJECTS.md
Main Programming Language: Rust
Alternative Programming Languages: Go, Elixir, C++
Coolness Level: Level 5: Pure Magic
Business Potential: 5. The “Industry Disruptor”
Difficulty: Level 5: Master
Knowledge Area: Language Design / Rule Systems
Software or Tool: Business Rules Engine
Main Book: “Language Implementation Patterns” by Terence Parr + “Domain Specific Languages” by Martin Fowler

What you’ll build: A production-grade business rules engine combining everything you’ve learned:

# Domain model
ENTITY Customer {
    id: UUID
    name: String
    tier: Enum(bronze, silver, gold, platinum)
    total_spent: Decimal
    registered_at: DateTime
    tags: List<String>
}

ENTITY Order {
    id: UUID
    customer: Customer
    items: List<OrderItem>
    total: Decimal
    created_at: DateTime
}

# Derived facts (computed at runtime)
FACT customer_lifetime_days(c: Customer) =
    days_between(c.registered_at, now())

FACT order_value_category(o: Order) =
    CASE
        WHEN o.total >= 1000 THEN "high"
        WHEN o.total >= 100 THEN "medium"
        ELSE "low"
    END

# Rules with priorities
RULESET pricing_rules {
    priority: 100  # Higher = runs first

    RULE loyal_customer_discount {
        WHEN customer_lifetime_days(order.customer) > 365
         AND order.customer.tier IN (gold, platinum)
        THEN
            APPLY discount(10%) TO order
            LOG "Applied loyal customer discount"
    }

    RULE bulk_order_discount {
        WHEN order.items.count() >= 10
        THEN
            APPLY discount(5%) TO order
    }

    # Rules can conflict - engine handles it
    RULE max_discount_cap {
        WHEN order.total_discount > 20%
        THEN
            SET order.total_discount = 20%
            LOG WARNING "Discount capped at 20%"
    }
}

RULESET fraud_detection {
    priority: 200  # Runs before pricing
    mode: short_circuit  # Stop on first match

    RULE suspicious_velocity {
        WHEN order.customer.orders_last_hour() > 5
        THEN
            FLAG order AS suspicious
            REQUIRE manual_review
            STOP  # Don't process more rules
    }
}

Why it teaches DSLs at the highest level: This project requires mastery of:

Complex grammar design
Type systems and semantic analysis
Efficient rule evaluation (Rete algorithm)
Conflict resolution strategies
Debugging and explanation facilities (“why did this rule fire?”)

Core challenges you’ll face:

Type system implementation (ensuring rules are type-safe) → maps to semantic analysis
Efficient pattern matching (Rete algorithm for rule networks) → maps to optimization
Conflict resolution (what happens when rules contradict?) → maps to priority systems
Explanation facility (“why did I get this result?”) → maps to debugging DSLs
Hot reloading (update rules without restart) → maps to runtime compilation
Performance at scale (thousands of rules, millions of facts) → maps to indexing/caching

Key Concepts:

Rete Algorithm: “Production Matching for Large Learning Systems” - Robert Doorenbos (PhD thesis)
Type Systems: “Types and Programming Languages” Chapters 1-3 - Benjamin Pierce
Semantic Analysis: “Engineering a Compiler” Chapter 4 - Cooper & Torczon
Rule Engine Architecture: Business Rules Engine Comparison 2024

Resources for key challenges:

Martin Fowler on Rules Engines - When to use (and not use) rules
Drools Documentation - Study a production rules engine
The Rete Algorithm - Efficient rule matching

Difficulty: Expert (Master level) Time estimate: 1-2 months Prerequisites: All previous projects, strong CS fundamentals

Real world outcome:

$ ./rules_engine --load business.rules --repl

Rules Engine v1.0 - 3 rulesets, 47 rules loaded

> fact Customer { id: "c1", name: "Alice", tier: gold, total_spent: 5000.00 }
Fact added: Customer(c1)

> fact Order { id: "o1", customer: @c1, items: [...], total: 500.00 }
Fact added: Order(o1)

> run
Evaluating Order(o1)...
  ✓ RULE loyal_customer_discount FIRED
    - Condition: customer_lifetime_days > 365 ✓ (was: 412 days)
    - Condition: tier IN (gold, platinum) ✓ (was: gold)
    - Action: Applied 10% discount ($50.00)
  ○ RULE bulk_order_discount SKIPPED
    - Condition: items.count() >= 10 ✗ (was: 3 items)

Final order total: $450.00 (was: $500.00)

> explain order(o1).discount
Order(o1) discount of $50.00 was applied because:
  1. RULE loyal_customer_discount (priority 100) matched:
     - customer_lifetime_days(Customer(c1)) = 412 > 365
     - Customer(c1).tier = gold, which is IN (gold, platinum)

  No other discount rules applied.
  Total discount: $50.00 (10%)

> --hot-reload business.rules
Rules reloaded (2 rules changed, 1 added)

Learning milestones:

Rules parse and type-check → You understand semantic analysis
Basic forward chaining works → You understand rule evaluation
Rete algorithm improves performance → You understand optimization
Explanation facility works → You understand rule tracing
Hot reload doesn’t lose state → You understand incremental compilation

Recommended Learning Path

Based on your starting point (complete beginner to DSLs), I recommend:

Start Here: Project 1 (Fluent Query Builder)

Why: Minimal parsing, focuses on API design. You’ll understand the mindset of DSL design—making code read like prose—without getting lost in lexer details.

Then: Project 2 (Config Parser)

Why: Introduces the fundamental lexer → parser → data structure pipeline. This pattern applies to every DSL you’ll ever build.

The Critical Jump: Project 3 (Filter Expressions)

Why: This is where you learn AST construction and evaluation. If you can build this, you can build almost any expression language.

Your Goal: Project 4 (Product Rules DSL)

Why: This is exactly what you asked for! By this point you’ll have the skills to design a custom language for your product catalog domain.

Optional Deep Dives:

Project 5 if you want compile-time metaprogramming (Elixir/Rust macros)
Project 6 if you want to build a template engine
Final Project if you want to build something enterprise-grade

Essential Resources

Books (In Order of Relevance)

“Crafting Interpreters” by Robert Nystrom - FREE at craftinginterpreters.com
- The absolute best introduction to building languages
- Covers lexing, parsing, interpreters, bytecode VMs
- Two complete implementations (Java and C)
“Domain Specific Languages” by Martin Fowler
- The definitive guide to DSL patterns
- Covers internal DSLs, external DSLs, language workbenches
- Use Chapter 35 for fluent interfaces, Chapter 11-12 for semantic models
“Language Implementation Patterns” by Terence Parr
- Practical patterns for language implementation
- Created by the author of ANTLR
- Great for understanding different parsing strategies
“Metaprogramming Elixir” by Chris McCord
- If you want to explore macro-based DSLs
- Written by the creator of Phoenix
- Excellent for understanding compile-time DSLs

Online Resources

Crafting Interpreters - Free, complete, excellent
Pratt Parsing Made Easy - Operator precedence parsing
Elixir School - Metaprogramming - Macro basics
The Rete Algorithm Explained - For rules engines

Domain-Specific Languages (DSLs) - Project-Based Learning Path

What You’ll Master

Project Comparison Table

Project 1: Fluent Query Builder (Internal DSL)

Project 2: Configuration File Parser (External DSL - Simple)

Project 3: Filter Expression Language

Project 4: Product Catalog Rules DSL

Project 5: Macro-Based HTML DSL (Compile-Time DSL)

Project 6: Template Engine with Custom Syntax

Final Project: Complete Business Rules Engine

Recommended Learning Path

Start Here: Project 1 (Fluent Query Builder)

Then: Project 2 (Config Parser)

The Critical Jump: Project 3 (Filter Expressions)

Your Goal: Project 4 (Product Rules DSL)

Optional Deep Dives:

Essential Resources

Books (In Order of Relevance)

Online Resources

Sources