DEV Community: Chris M. Pérez

Pudu Programming Language

Chris M. Pérez — Sat, 19 Sep 2026 02:12:42 +0000

Pudu is a statically typed, expression-oriented programming language that I’m designing for building services, developer tools, and native applications. The project is still young and is currently moving toward its first 0.1.0 pre-release, but it has grown well beyond the stage of being a syntax experiment. Today, the repository contains the language implementation, standard library, testing infrastructure, development tools, editor integration, documentation, examples, and the foundations of the ecosystem I want to build around it.

I think this is the right point to start talking more openly about why Pudu exists, what I’m trying to accomplish with it, and where I want to take the language.

The source code is available on GitHub:

https://github.com/chrismichaelps/pudu-lang

Why Pudu?

Creating another programming language in 2026 naturally raises a question: why?

We already have an extraordinary number of good languages. Rust has pushed systems programming toward stronger safety guarantees. Haskell has demonstrated how far expressive type systems and functional programming can go. OCaml has spent decades showing how practical and elegant the ML family can be. Go demonstrated the value of simplicity and excellent tooling. TypeScript transformed the experience of working with large JavaScript codebases.

Pudu does not exist because I believe those languages have failed.

It exists because programming languages are collections of trade-offs, and I wanted to explore a particular combination of them.

One of the ideas behind Pudu is that important uncertainty in a program should be visible. If an operation can fail, that possibility should be represented by its type. If a value can be absent, that absence should be explicit. If a program branches over every possible form of a type, the compiler should be able to tell us when one of those possibilities has been forgotten.

At the same time, I don't want those guarantees to require writing code that feels unnecessarily academic or complicated.

That balance—expressiveness, explicitness, safety, and practical usability—is one of the central design problems I’m exploring with Pudu.

What Pudu looks like

A small Pudu program currently looks like this:

module Shapes

import Std.Io as Io

type Shape
  = Circle(Float)
  | Rectangle(Float, Float)

fn area(shape: Shape) -> Float {
  match shape {
    case Circle(radius) => 3.14159 * radius * radius
    case Rectangle(width, height) => width * height
  }
}

export fn main() -> Result[(), Str] {
  for shape in [Circle(1.0), Rectangle(3.0, 4.0)] {
    Io.writeLine(show(area(shape))) ?
  }

  Ok(())
}

There are several parts of Pudu's philosophy hidden inside this relatively small example.

Shape is not represented through an arbitrary integer, string, or inheritance hierarchy. It is a type with a finite set of possible forms. A Shape is either a Circle containing a radius or a Rectangle containing a width and height.

When the value is inspected with match, those possibilities become explicit.

More importantly, matching is exhaustive. If the definition of Shape evolves and another case is introduced, code matching against that type should not quietly continue while forgetting that the new state exists.

I like this property because it changes the relationship between the programmer and the compiler. The compiler is not simply translating syntax into something executable. It is participating in the process of maintaining the assumptions encoded in the program.

That idea appears repeatedly throughout Pudu.

Making failure visible

Error handling is one of the areas where programming languages make very different philosophical choices.

In Pudu, ordinary recoverable failure is intended to be represented as a value.

A function that can fail can expose that directly through its signature:

fn loadConfig(path: Str) -> Result[Config, Error]

You do not need to inspect the implementation or documentation to discover that loadConfig may fail. The possibility is part of the function's contract.

Pudu also provides ? for propagating failure without turning every operation into deeply nested control flow.

let config = loadConfig("pudu.toml") ?

This does not mean that Pudu somehow eliminates runtime failures. That would be an unrealistic promise for a general-purpose programming language. Instead, the objective is narrower and more useful: failures that we reasonably expect software to handle should be difficult to accidentally ignore.

The same philosophy applies to absence. Rather than allowing a null value to appear almost anywhere, absence can be represented intentionally through types such as Option[T].

A value is either present or absent, and code interacting with it has enough information to reason about both possibilities.

These concepts are not inventions unique to Pudu. Languages from the ML family, Haskell, Rust, Swift, and others have demonstrated variations of them for years. What interests me is how these ideas can be combined into a language that remains approachable while still providing strong foundations for larger programs.

Expression-oriented by design

Pudu is also expression-oriented.

I have always liked languages where constructs compose naturally rather than being divided into many artificial categories of statements and expressions. If something logically produces a value, the language should generally make it possible to use that value directly.

This has implications beyond syntax.

Expression-oriented programming encourages data flow that can often be easier to reason about. Instead of creating temporary mutable state merely to communicate the result of a branch or computation, the result can become part of the expression itself.

Pudu is influenced here by languages such as Haskell, OCaml, Rust, and other members of the functional and ML traditions, but I am deliberately avoiding the goal of cloning any particular language.

Influence is useful. I don't think imitation is enough reason to create a programming language.

Pudu needs to develop its own identity and its own answers to these problems.

A language is more than its syntax

One lesson that became increasingly clear while building Pudu is that designing syntax is probably the easiest part of creating a programming language.

The difficult work begins when that syntax needs semantics.

The parser needs to recover intelligently from incomplete programs. The type checker needs to understand what the programmer intended and explain when those expectations cannot be satisfied. Modules need predictable resolution rules. Diagnostics need stable source locations. The standard library needs coherent conventions. Editor tooling needs to understand programs while they are being written, not only after they successfully compile.

Then everything has to work together.

Because of that, I don't consider Pudu to be only the language grammar. I think of Pudu as the complete development environment surrounding the language.

The project currently uses a single pudu executable as its primary interface. That executable is responsible for operations such as checking programs, running them, testing projects, formatting source code, linting, generating documentation, bundling programs, and serving editor functionality through the Language Server Protocol.

The intended experience is deliberately straightforward:

pudu init hello
cd hello
pudu run src/Main.pudu
pudu test

Editor support is exposed through:

pudu lsp

A VS Code extension is also being developed alongside the language.

I want the tooling to feel like part of Pudu rather than an ecosystem of unrelated programs that users have to discover and assemble themselves.

Installing a programming language should get you much closer to actually programming in that language.

Building the implementation in Haskell

The Pudu implementation is currently being developed in Haskell.

For a compiler project, Haskell provides a number of useful properties. Algebraic data types map naturally to syntax trees and intermediate representations. Pattern matching works well for compiler transformations. Strong typing makes many invalid internal states harder to construct, and functional composition fits naturally with the different phases of a compiler.

But using Haskell does not mean Pudu is intended to become Haskell with different syntax.

Pudu has its own design goals.

The implementation language is a tool used to build those ideas, not a restriction on what the final language should become.

Working on the compiler has also changed how I think about programming languages in general. Features that appear almost trivial from the outside quickly turn into deeper design questions.

What happens after the parser encounters malformed syntax? How much should it recover before continuing? When two interpretations of an expression are possible, which rule wins? What information should survive from parsing into type checking? How should generic types be represented? What makes an error message genuinely useful instead of merely technically correct?

Once you build a compiler, things that previously looked like language syntax start looking like contracts between multiple systems.

That has probably been the most interesting part of the project for me.

Compiler diagnostics matter

One area I care particularly about is diagnostics.

A compiler error is a user interface.

When something is wrong, telling the programmer that the program is invalid is technically correct but practically insufficient. A useful compiler should identify where the problem originated, explain what it expected, preserve enough context to make the message understandable, and avoid producing a cascade of unrelated errors caused by the first mistake.

This becomes particularly important for editor integration.

Developers spend much more time working with incomplete programs than perfectly valid ones. Every few keystrokes, a source file may temporarily contain missing delimiters, unfinished expressions, incomplete generic arguments, or unresolved names.

A parser and language server that only behave well when the program is already valid do not provide a good development experience.

For that reason, parser recovery, diagnostics, and LSP behavior are not things I want to bolt onto Pudu after the language is "finished." They are part of the language engineering itself.

Why the name Pudu?

The name comes from the pudu, a small deer native to South America.

Programming languages often end up with highly technical names, acronyms, or names intended to communicate something about their implementation. I wanted something simpler: short, recognizable, easy to say, and capable of developing an identity of its own.

I came across the pudu and liked the name.

Sometimes that is enough.

As the project has grown, the name has also made it possible to develop a visual identity around the language without tying that identity to a particular implementation detail that might change later.

Where Pudu actually stands today

I think transparency is particularly important when talking about a new programming language.

Pudu is currently pre-release software.

The first milestone is 0.1.0, not 1.0, and that distinction matters.

Programs are currently interpreted. Dependencies are local directories. Platform support remains limited. Some language semantics will change. APIs will evolve. Parts of the standard library will be redesigned as real programs expose weaknesses in the current design.

I don't want to hide those limitations behind ambitious language.

Building a mature programming language and ecosystem takes years. Rust, Go, Swift, Kotlin, and other successful languages did not become what they are today with their first release.

The purpose of Pudu 0.1 is therefore not to claim that the language is finished.

It is to establish a credible foundation.

I want the language, compiler, standard library, documentation, tooling, editor integration, tests, examples, and development workflow to reach a point where other developers can meaningfully experiment with Pudu and provide useful feedback.

That is a much more valuable milestone than prematurely declaring stability.

Where I want to take it

The longer-term direction is to make Pudu capable of building serious software while keeping the language understandable.

I want a language where the type system helps communicate intent without dominating every program. I want error handling to remain explicit without becoming repetitive. I want pattern matching and algebraic data types to feel natural rather than advanced. I want compiler diagnostics that developers can actually learn from.

I also want tooling to remain a first-class concern as the project grows.

It is easy for a language to accumulate independent tools over time until basic development requires configuring a compiler, formatter, linter, test runner, package manager, language server, documentation generator, and build system independently.

Pudu has an opportunity that mature languages often don't have: these decisions can be considered together from the beginning.

Performance is another important part of the long-term work. The current interpreter is appropriate for developing and validating the language, but it is not the end of the story. Moving toward serious native applications will eventually require increasingly sophisticated compilation and optimization work.

I would rather approach that incrementally and measure the results than make performance claims before the implementation can support them.

What building Pudu has taught me

Building Pudu has made me appreciate how much invisible engineering exists underneath a mature programming language.

As developers, we write if, match, call a generic function, import a module, or ask an editor for autocomplete without thinking much about what happens underneath.

When you build the language yourself, none of those behaviors simply exist.

Someone has to define what a module actually means. Someone has to determine when two types are compatible. Someone has to decide whether a parser should stop or recover after an error. Someone has to define precedence, name resolution, visibility, generic substitution, diagnostics, package boundaries, source locations, formatting rules, and hundreds of other details.

And once those decisions are made, they have to remain coherent with one another.

That has become one of my favorite parts of this project.

Pudu is not only an attempt to create another programming language. It has become a way for me to study programming languages at a much deeper level by actually building one.

The road to 0.1

Right now, my focus is getting the foundations right.

I would rather spend more time fixing inconsistencies in the language, improving diagnostics, strengthening the standard library, testing edge cases, and polishing the development experience than rush toward a version number.

There will be plenty of opportunities to add features later.

The difficult part is deciding which foundations should remain when those features arrive.

Pudu 0.1 will still be experimental. That is expected. What I want it to demonstrate is that the ideas behind the language can work together as a coherent system.

From there, real programs and real developers can begin challenging those assumptions.

That feedback is ultimately how the language will improve.

This is only the beginning

Pudu is still a small project compared with established programming languages, and there is a significant amount of engineering ahead.

That's also what makes this stage exciting.

The architecture is still evolving. Some decisions can still be reconsidered. The standard library is still taking shape. The compiler can still change substantially. There are still opportunities to experiment before compatibility requirements make those decisions much more expensive.

I'm building Pudu in the open, and the project is available on GitHub.

If you're interested in programming languages, compiler engineering, type systems, language tooling, or open-source development, you're welcome to explore the source code, try the language, open an issue, contribute, or simply follow the project as it develops.

Pudu doesn't need to pretend to be the future of programming.

Right now, it needs to become a good programming language.

That's the challenge I'm interested in solving.

Pudu is currently heading toward its 0.1.0 pre-release.

https://github.com/chrismichaelps/pudu-lang

Why I Built ACP: A Coordination Platform for Autonomous Coding Agents

Chris M. Pérez — Sun, 05 Jul 2026 16:24:07 +0000

As coding agents continue to improve, I've noticed that the hardest problems are no longer about generating code. Claude Code, Codex, Gemini CLI, Cursor, and other agents are already capable of implementing features, refactoring applications, writing tests, and navigating large repositories with very little guidance.

The real challenge begins when multiple autonomous workers need to collaborate on the same project.

Most development tooling was designed around humans. Git records history, GitHub manages collaboration, CI systems automate builds, and editors provide an interface for writing code. Those tools work extremely well because humans naturally communicate outside the system. We discuss implementation details in Slack, leave comments on pull requests, create tickets, and coordinate work through meetings.

AI agents don't have those implicit communication channels.

Every agent starts from its own context window. It doesn't know whether another worker is already implementing the same feature, whether a file is currently being modified, which decisions have already been made, or what work remains after another agent terminates unexpectedly. As more autonomous workers participate in software development, coordination becomes a systems problem rather than a prompting problem.

That observation led me to build ACP.

Unlike existing agent protocols that focus on communication between clients and models or interoperability between agents, ACP focuses on something different: shared operational state inside a software project. The goal is to provide a durable coordination layer that allows autonomous workers to safely collaborate on the same repository.

Instead of treating conversations as the source of truth, ACP models the state of collaborative software engineering itself.

A workspace becomes the boundary where work happens. Workers represent autonomous actors, whether they're AI agents, humans, CI pipelines, or automation. Work is represented through explicit work units with predictable lifecycle transitions instead of loosely defined tasks. Shared resources can be coordinated using advisory leases, allowing workers to understand ownership without relying on operating-system locks. Long-running execution can be resumed through checkpoints, while durable memory records preserve the information another worker actually needs to continue the job. Reviews, artifacts, and event history complete the lifecycle so every important action becomes part of the operational history of the workspace.

One design decision that significantly influenced ACP is the idea that coordination should be event-driven.

Rather than simply mutating database records, important operations generate immutable events describing what happened. A worker claims a work unit. A lease is acquired. Progress is checkpointed. A review is requested. An artifact is attached. Work is approved and eventually completed.

This event history becomes far more valuable than a chat transcript because it allows any worker to reconstruct the current state of the workspace without needing access to the original conversation. If an agent crashes, a CI job restarts, or another model takes over the task, recovery is based on durable state rather than reconstructed prompts.

Another important architectural goal was separating coordination semantics from infrastructure.

Whether clients communicate through REST, JSON-RPC, Server-Sent Events, or native Effect RPC should not change the underlying behavior of the platform. Likewise, whether persistence is backed by in-memory storage during development, SQLite on a workstation, or PostgreSQL in production should not affect how work units, leases, checkpoints, or reviews behave. Infrastructure can evolve independently while the coordination model remains consistent.

The implementation reflects that philosophy throughout the repository.

ACP is built with TypeScript and the Effect ecosystem, using Effect's dependency graph, typed errors, schema validation, configuration system, and runtime abstractions to keep each subsystem isolated and composable. The project separates protocol definitions, domain logic, infrastructure adapters, transports, storage implementations, and application entry points into independent layers, making it possible to evolve individual components without affecting the rest of the platform.

One aspect I'm particularly happy with is that ACP is not tied to a single execution environment. The same coordination model can support local repositories, Git worktrees, development containers, cloud sandboxes, or CI pipelines. Workers don't need to know where they're running—they only need to understand the shared coordination state exposed by the platform.

ACP is intentionally not another AI framework.

It doesn't generate code.

It doesn't orchestrate prompts.

It doesn't replace Git.

It doesn't compete with MCP or other agent communication protocols.

Instead, ACP sits one layer below autonomous software engineering, providing the durable operational primitives that allow independent workers to collaborate safely over long-running tasks.

Building ACP has reinforced something I've been thinking about for a while.

The first generation of AI developer tools focused on making individual developers more productive. The next generation will focus on enabling entire teams of autonomous workers to collaborate effectively. Once that happens, the difficult engineering problems won't be language models—they'll be ownership, recovery, synchronization, review workflows, auditability, and distributed coordination.

That's the problem ACP is exploring.

The project is still evolving, and many ideas will undoubtedly change over time. But I believe the underlying premise is sound: autonomous software engineering needs the same kind of operational infrastructure that distributed systems required years ago. As agents become more capable, coordination becomes infrastructure—not an implementation detail.

If you'd like to explore the architecture or contribute ideas, the repository is open source:

GitHub: https://github.com/chrismichaelps/acp

Beyond Prompt Engineering: Why Your AI Architecture Is Leaking Tokens (And How to Fix It with FMCF)

Chris M. Pérez — Fri, 27 Feb 2026 22:33:54 +0000

We have all hit the "stochastic wall." You start a development project with a top-tier AI model—whether it is GPT-4o, Claude 3.5, or a specialized local LLM—and for the first twenty minutes, the speed is incredible. However, as the codebase grows and the conversation history deepens, a subtle but destructive breakdown begins to set in.

Regardless of your experience level, the symptoms are the same: Context Smog, Architectural Drift, and the dreaded Hallucination Loop. The model starts to "forget" logic established just a few turns ago, or worse, it starts making up rules that violate your project’s core DNA.

Having a background in traditional coding means I value precision, but I found myself manually correcting AI outputs too often. I needed a system where the AI worked as a reliable partner rather than an unpredictable assistant. This led to the development of FMCF (Fibonacci Matrix Context Flow). This is not just a clever prompt; it is a universal architectural rulebook that transforms the AI into a high-precision machine.

1. The Core Constraint: Second-Order Markov Determinism

The main challenge with AI models is their random nature; they predict the next word based on probability rather than solid logic. When too much information piles up in the "chat history," the model struggles to focus on what actually matters.

FMCF fixes this by enforcing Second-Order Markov Determinism. In this setup, the next step ($V_{n+1}$) is a strict result of only the current state ($V_n$) and the one right before it ($V_{n-1}$). By explicitly declaring everything outside this two-step window as Null-Space, we clear out the "extra noise" and "zombie logic" that usually leads to AI mistakes. This ensures the model stays grounded in the immediate architectural context.

2. The Dual-Track Registry: Planning Before Building

FMCF uses a Hash-First Hard-Lock to make sure that the actual building never gets ahead of the design. We split the work into two distinct areas, or "planes":

Track 1: The Implementation Plane (The Shadow): This is where the actual code lives. Only small, specific changes (Targeted Line Injections) are allowed here to prevent unexpected side effects across the file.
Track 2: The Hash Registry Plane (The Source): This is the system's "truth" layer. Before a single line of code is written, the AI must update records like .contract.json (input/output rules), .logic.md (step-by-step plans), and .chronos.json (the history of "why" a change was made).

The `local.map.json` / `.index.json` (Dynamic Topology)

To manage these tracks, FMCF uses a topology schema to track every module's state and dependencies:

{
  "shard_id": "@root/src/module",
  "state_anchor": "BigInt:0x...",
  "parent_bridge": "@root/hashes/local.map.json",
  "git_anchor": "HEAD_SHA",
  "cache_integrity": "VERIFIED | STALE",
  "nodes": {
    "module_name": {
      "file_path": "@root/src/module/file.ts",
      "hash_reference": "@root/hashes/module/file.hash.md",
      "grammar_ref": "@root/hashes/grammar/[lang].hash.md",
      "dependencies": ["@root/hashes/dep.contract.json"],
      "fidelity_level": "Active | Signature | Hash"
    }
  }
}

The AI is strictly forbidden from writing code until these registry files are updated and verified. This creates a deterministic link between intent and execution.

3. The Cache Trust Protocol: Eliminating Stale State

LLM sessions are volatile and "forgetful." When you start a new session or upload files, how do you know the AI actually "understands" the current state of the project? FMCF solves this with the Cache Trust Protocol.

Before a single line of logic is processed, the AI must perform an Integrity Handshake:

Sample: Pick 3 random entries from the /hashes/ directory.
Validate: Re-compute the hashes of the source files and compare them to the registry.
Verdict: If they match, the cache is VERIFIED. If not, it is STALE, and a full re-scan is mandatory.

4. Fixing Errors: Active Grammar Shards

A major frustration in AI development happens when a model writes code that immediately causes errors because it relied on its general training data instead of your project’s specific needs.

In FMCF, I added Step -0.5: Signature Discovery. Before writing code, the AI must scan your environment—specifically your package.json or setup files—to lock its "grammar" to the versions you actually use.

The `grammar/[lang].hash.md` (Linguistic DNA)

This shard acts as the "Hard Compiler Constraint" for the AI's syntax:

---
Language: [e.g., TypeScript | Rust | Solidity]
Version: [e.g., 5.x | 1.75 | 0.8.20]
Fidelity: 100% (Static Reference)
---
## [Syntax_Rules]
- (e.g., Strict Null Checks)
- (e.g., Functional composition over classes)

## [Naming_Conventions]
- (e.g., camelCase for variables, PascalCase for components)

## [Import_Order]
- (e.g., External libraries, Internal modules, Types)

## [Prohibited_Patterns]
- (e.g., No explicit 'any', No 'var')

## [Standard_Library_Signatures]
- (Immutable reference to core methods to avoid tokenized re-learning)

By anchoring the AI's "Grammar Handshake" to these specific rules, we prevent repetitive syntax errors and save thousands of tokens.

5. The Forensic Audit: Keeping the AI Honest

To keep the system fast and efficient, the prompt includes a dedicated Forensic Audit layer. This role acts as a Treasurer, checking the session for wasted space and "leaking" tokens.

The `.chronos.json` (Forensic Ledger)

Every change is logged here to maintain a clear audit trail of intent:

{
  "timeline": [{
    "state_id": "BigInt:0x...",
    "logic_delta": { "intent": "Brief 'Why'", "risk": "High|Med|Low" },
    "commit_ref": "SHA_7"
  }]
}

The Treasurer audits the session, verifying:

Context Cleanup: Making sure old, unneeded information (Context Smog) has been cleared out.
Role Integrity: Confirming that specific specialists (like the Architect) didn't try to write implementation code.
Traceability: Ensuring every change has a clear explanation of "Why" it was made in the logic_delta.

If the session gets too cluttered or the Token Efficiency Score drops below the Golden Ratio ($61.8\%$), the system triggers a hard reset (World State Vector) to start fresh.

6. The Power of Model Sinergy

FMCF doesn't just help powerful models; it levels the playing field for smaller models too.

For High-Tier Models: It acts as a set of guardrails, preventing the model from over-complicating logic or drifting from the architectural plan.
For Small/Local Models: The fragmented "sharded" nature of the metadata allows these models to process specific contracts without needing to hold the entire project context in their limited memory.

By using the Hash-First Hard-Lock, even a smaller model can perform complex updates reliably because the "logic" is pre-defined in Track 2 before it ever attempts to touch the code in Track 1.

Why This Matters for All Developers

Whether you are a junior dev just starting out or a seasoned pro, you do not need an AI that "guesses"; you need a partner that follows your rules exactly. FMCF makes the AI's logic clear, tracked, and predictable. It turns AI coding from a gamble into a forensic process.

The Hash is the Truth. The Grammar is the Law. The History is the Evidence.

Explore the full repo and get the Master Seeds for your own projects here:
https://github.com/chrismichaelps/FMCF

Tagix: My Experimental State Management Library

Chris M. Pérez — Sun, 08 Feb 2026 16:38:49 +0000

Tagix: My Experimental State Management Library

Every time I write a state handler, I find myself asking the same question: What happens if I miss a case?

State management is about transitions. Your application moves from one state to another, and your code needs to handle every possibility. But humans miss things. We forget edge cases. We assume certain states won't happen.

What if TypeScript could help? What if, instead of relying on tests to catch missed handlers, we could make TypeScript do that work for us?

That's the question that started Tagix.

The Problem I Was Trying to Solve

I wanted to write state transitions where missing a case would be a type error, not a runtime bug.

Consider this state that can be in one of four conditions:

type UserState =
  | { status: "idle" }
  | { status: "loading" }
  | { status: "authenticated"; user: User }
  | { status: "error"; message: string };

In most state management libraries, you'd write a reducer that handles these cases. If you forget one, the application might crash when that unexpected state occurs. Your tests might catch it, or they might not.

But TypeScript's discriminated unions give us something powerful: the ability to narrow types based on runtime values. When you check state.status === 'authenticated', TypeScript knows inside that branch that state.user exists.

I wanted to build a state management library that leveraged this—not as an optional feature, but as the default way of working with state.

My Core Insight

The insight was simple: state should be defined as tagged unions, and state transitions should be functions that return one of those tagged variants.

No action dispatching in the traditional sense. No action types as strings. No middleware pipeline. Just state, transitions, and TypeScript making sure you didn't miss anything.

Here's what that looks like in Tagix:

const UserState = taggedEnum({
  Idle: {},
  Loading: {},
  Authenticated: { user: User },
  Error: { message: string },
});

From this definition, Tagix generates:

A discriminated union type for the state
Constructor functions for each variant
Type guards for runtime checks
A pattern matcher for declarative handling

When you create an action, you're creating a function that takes the current state and returns a new state:

const login = createAction<{ email: string; password: string }, typeof UserState.State>("login")
  .withPayload({ email: "", password: "" })
  .withState(async (_, { email, password }) => {
    const result = await attemptLogin(email, password);

    if (result.ok) {
      return UserState.Authenticated({ user: result.user });
    }

    return UserState.Error({ message: result.error });
  });

The key point isn't the API—it's that this function must return a valid UserState. TypeScript won't let you return anything else. If you try to return an invalid state, you'll know immediately.

Why Pattern Matching Matters

I spent a lot of time thinking about how developers would read state in their components. Most libraries use selectors or subscriptions. These work, but they don't leverage TypeScript's type narrowing.

In Tagix, you use the $match function:

function displayUser(state: UserState): string {
  return UserState.$match(state, {
    Idle: () => "Waiting to start...",
    Loading: () => "Loading your account...",
    Authenticated: ({ user }) => `Welcome back, ${user.email}!`,
    Error: ({ message }) => `Something went wrong: ${message}`,
  });
}

This function handles every state variant. Add a new variant to UserState, and TypeScript forces you to add a handler here. No default case to forget, no implicit fallthrough.

The benefit is confidence. When your code type-checks, you've handled every possible state.

The Core Abstractions

Tagix is built around three fundamental abstractions that work together. Understanding these will help you use the library effectively.

Tagged Enum

The taggedEnum function creates a state constructor and a set of type utilities:

const UserState = taggedEnum({
  Idle: {},
  Loading: {},
  Authenticated: { user: User },
  Error: { message: string },
});

This single line does a lot of work. First, it creates a type UserStateType that is the union of all variants. Second, it creates constructor functions for each variant (UserState.Idle(), UserState.Loading(), etc.). Third, it creates a $match function for pattern matching. Fourth, it creates $is type guards for each variant.

The constructors are particularly useful because they create both the runtime value and the type simultaneously:

const authenticatedState = UserState.Authenticated({ user: { id: "1", name: "Alice" } });
// authenticatedState has type: { _tag: 'Authenticated'; user: User }

Actions

Actions in Tagix are different from what you might have used elsewhere. An action is a function that takes the current state and returns a new state:

const login = createAction<{ email: string; password: string }, typeof UserState.State>(
  "user/login"
)
  .withPayload({ email: "", password: "" })
  .withState(async (_, { email, password }) => {
    const result = await attemptLogin(email, password);

    if (result.ok) {
      return UserState.Authenticated({ user: result.user });
    }

    return UserState.Error({ message: result.error });
  });

The key insight is that actions return state directly. There's no dispatching to a reducer, no action types to match, no switch statements. Your action is your state transition.

The .withPayload() and .withState() calls set up type inference. The .withPayload<PayloadType>() tells Tagix what shape the payload has. The .withState() tells Tagix what state this action works with.

The Store

The store ties everything together:

const userStore = createStore(UserState.Idle({}), UserState);

userStore.register(login);

userStore.dispatch(login, { email: "test@example.com", password: "secret" });

The store holds the current state and handles action dispatching. When you register an action, the store knows which actions are available. When you dispatch an action, the store calls it with the current state.

You can subscribe to state changes:

userStore.subscribe((state) => {
  console.log("State changed:", state);
});

Async Actions

Real-world applications have async operations. Tagix handles this naturally because action functions can be async:

const loadUserData = createAction<{ userId: string }, typeof UserState.State>("user/load-data")
  .withPayload({ userId: "" })
  .withState(async (_, { userId }) => {
    try {
      const data = await fetchUserData(userId);
      return UserState.Ready({ data, loadedAt: new Date() });
    } catch (error) {
      return UserState.Error({
        message: error instanceof Error ? error.message : "Unknown error",
        userId,
      });
    }
  });

The store handles awaiting automatically. While the promise resolves, the state is in whatever variant you returned first.

Designing State Machines

One of the benefits of Tagix is that it encourages thinking about your state as a proper state machine. Every state is a variant, every transition is explicit.

Here's how I'd design an authentication flow:

const AuthState = taggedEnum({
  Unauthenticated: {},
  Authenticating: { email: string },
  Authenticated: {
    user: User;
    sessionExpiresAt: Date;
    permissions: string[]
  },
  SessionExpired: { user: User },
  LoggingOut: {},
});

const login = createAction<{ email: string; password: string }, typeof AuthState.State>(
  'auth/login'
).withPayload({ email: "", password: "" })
  .withState(async (_, { email, password }) => {
    const result = await verifyCredentials(email, password);

    if (result.ok) {
      const session = await createSession(result.userId);
      return AuthState.Authenticated({
        user: result.user,
        sessionExpiresAt: session.expiresAt,
        permissions: result.permissions,
      });
    }

    return AuthState.Unauthenticated();
  });

const logout = createAction<void, typeof AuthState.State>(
  'auth/logout'
).withPayload()
  .withState(() => {
    clearSession();
    return AuthState.Unauthenticated();
  });

const checkSession = createAction<void, typeof AuthState.State>(
  'auth/check-session'
).withPayload()
  .withState(async (currentState) => {
    if (AuthState.$is('Authenticated')(currentState)) {
      const isValid = await verifySession(currentState.sessionExpiresAt);

      if (!isValid) {
        return AuthState.SessionExpired({ user: currentState.user });
      }
    }

    return currentState;
  });

Notice how every action has a clear entry and exit point. You can look at any action and understand what states it can produce. You can look at any state and understand how you got there.

Error Handling Patterns

Tagix works well with error boundaries and recovery flows:

const DataState = taggedEnum({
  Initial: {},
  Loading: {},
  Ready: { data: Data },
  Error: { error: ErrorInfo; retryCount: number },
});

const loadData = createAction<void, typeof DataState.State>(
  'data/load'
).withPayload()
  .withState(async (currentState) => {
    if (DataState.$is('Error')(currentState) && currentState.retryCount >= 3) {
      return currentState;
    }

    try {
      const data = await fetchData();
      return DataState.Ready({ data });
    } catch (error) {
      const retryCount = DataState.$is('Error')(currentState)
        ? currentState.retryCount + 1
        : 1;

      return DataState.Error({
        error: {
          message: error instanceof Error ? error.message : 'Unknown error',
          code: 'FETCH_ERROR',
        },
        retryCount,
      });
    }
  });

const resetError = createAction<void, typeof DataState.State>(
  'data/reset-error'
).withPayload()
  .withState(() => {
    return DataState.Initial();
  });

The error state includes a retryCount, allowing you to implement backoff strategies or give up after a certain number of attempts.

Combining State Machines

Real applications often have multiple state machines that interact. Here are approaches that work:

Parallel State Machines

If you have independent state machines (like a user session and a modal dialog), you can combine them:

const UserState = taggedEnum({
  /* ... */
});
const ModalState = taggedEnum({
  /* ... */
});

type AppState = {
  user: typeof UserState.State;
  modal: typeof ModalState.State;
};

const appStore = createStore({
  user: UserState.Idle({}),
  modal: ModalState.Closed({}),
});

const openSettings = createAction<void, typeof AppState.State>("app/open-settings")
  .withPayload()
  .withState((currentState) => ({
    ...currentState,
    modal: ModalState.Settings({}),
  }));

Nested State Machines

For dependent state machines, you can nest one inside another:

const CheckoutState = taggedEnum({
  Cart: { items: CartItem[] },
  Shipping: { shippingInfo: ShippingInfo; shippingMethod: string },
  Payment: { shipping: ShippingInfo; paymentMethod: PaymentMethod },
  Complete: { orderId: string },
});

const AppState = taggedEnum({
  Shopping: { checkout: typeof CheckoutState.State },
  Browsing: { cart: CartItem[] },
});

function checkoutWithCart(cart: CartItem[]): AppState {
  return AppState.Shopping({
    checkout: CheckoutState.Cart({ items: cart }),
  });
}

Performance Considerations

Tagix is designed to be minimal in runtime overhead. Here are some patterns for keeping things fast:

Selective Subscriptions

You don't always need to subscribe to the entire state:

store.subscribe((state) => {
  if (UserState.$is("Authenticated")(state)) {
    updateUI(state.user);
  }
});

Memoization with Selectors

For derived data, use memoization:

import { memoize } from "tagix";

const selectUserDisplayName = memoize((state: UserState): string => {
  return UserState.$match(state, {
    Authenticated: ({ user }) => user.displayName,
    Loading: () => "Loading...",
    Idle: () => "Not logged in",
    Error: () => "Error",
  });
});

const displayName = selectUserDisplayName(store.stateValue);

Common Patterns

Here are patterns that emerge naturally when using Tagix:

Initialization Actions

Many applications have an initialization phase:

const AppState = taggedEnum({
  Initializing: { progress: number },
  Ready: { user: User; config: AppConfig },
  Failed: { error: string },
});

const initializeApp = createAction<void, typeof AppState.State>(
  'app/initialize'
).withPayload()
  .withState(async () => {
    const progress = { current: 0, total: 3 };

    const config = await loadConfig();
    progress.current++;

    const user = await loadUser();
    progress.current++;

    const preferences = await loadPreferences();
    progress.current++;

    return AppState.Ready({ user, config: { ...config, preferences } });
  });

Optimistic Updates

For better user experience, you can update the UI optimistically:

const toggleTodo = createAction<{ id: string }, typeof TodoState.State>("todos/toggle")
  .withPayload({ id: "" })
  .withState((currentState, { id }) => {
    if (TodoState.$is("Ready")(currentState)) {
      const updated = currentState.items.map((item) =>
        item.id === id ? { ...item, completed: !item.completed } : item
      );
      return TodoState.Ready({ items: updated });
    }
    return currentState;
  });

Undo/Redo

Implementing undo/redo is straightforward with Tagix:

const EditableState = taggedEnum({
  Current: { document: Document },
  UndoStack: { current: Document; history: Document[] },
  RedoStack: { current: Document; history: Document[] },
});

const undo = createAction<void, typeof EditableState.State>(
  'editor/undo'
).withPayload()
  .withState((currentState) => {
    if (EditableState.$is('Current')(currentState)) {
      return currentState;
    }

    if (EditableState.$is('UndoStack')(currentState)) {
      const [previous, ...remaining] = currentState.history;
      return EditableState.Current({ document: previous });
    }

    return currentState;
  });

Testing Strategies

Tagix's explicit state transitions make testing straightforward:

describe("login action", () => {
  it("transitions to Authenticated on success", async () => {
    const mockState = UserState.Idle({});
    const mockPayload = { email: "test@example.com", password: "secret" };

    const result = await loginAction(mockState, mockPayload, {
      attemptLogin: async () => ({ ok: true, user: { id: "1", name: "Test" } }),
    });

    expect(UserState.$is("Authenticated")(result)).toBe(true);
    if (UserState.$is("Authenticated")(result)) {
      expect(result.user.name).toBe("Test");
    }
  });

  it("transitions to Error on failure", async () => {
    const mockState = UserState.Idle({});
    const mockPayload = { email: "test@example.com", password: "wrong" };

    const result = await loginAction(mockState, mockPayload, {
      attemptLogin: async () => ({ ok: false, error: "Invalid credentials" }),
    });

    expect(UserState.$is("Error")(result)).toBe(true);
  });
});

The explicit transitions mean you can test each possible path through your state machine.

A Honest Note About Scope

Tagix isn't trying to compete with established libraries. Redux has a decade of ecosystem, DevTools, and community patterns. Zustand is minimal and works incredibly well for most use cases. MobX has influenced how we think about reactivity.

Tagix is different—an experiment in taking TypeScript's type system seriously for state management. It makes certain trade-offs that larger libraries wouldn't:

Your state must be a discriminated union
You need to think about state transitions upfront
The ecosystem is newer and smaller

If you're already happy with your current state management solution, Tagix isn't trying to convince you to switch. But if you've wished for stronger type guarantees, or experienced runtime bugs from missing state handlers, Tagix might be worth exploring.

The Design Decisions

Building Tagix forced me to make choices. Here are the important ones:

Decision 1: No Action Types as Strings

Other libraries use strings like 'USER_LOGIN_REQUEST' to identify actions. In Tagix, actions are functions. When you dispatch login, you're dispatching the login function. No string comparison happens.

You can't accidentally dispatch the wrong action type. No typos in action constants. The function is the action.

Decision 2: Actions Return State Directly

In Redux, actions are dispatched and reducers handle them. In Tagix, actions are the state transition logic. The action function receives the current state and returns the new state.

The flow is obvious. No middleware intercepting actions, no mysterious state updates in reducers you didn't write. Your action is your state transition.

Decision 3: Exhaustive Pattern Matching

Every time you use $match, you're forced to handle every variant. No partial handlers, no forgotten cases.

This isn't always convenient—there are times when you genuinely don't care about certain states—but it's consistent. You always know what states you're handling.

What I Learned

Building Tagix taught me several things about state management and type systems:

First, design matters more than implementation. The way you model your state affects everything downstream. Tagged unions encourage thinking about state as distinct modes rather than collections of properties.

Second, type systems can do more than we typically ask. We're used to TypeScript catching type mismatches. But it can also enforce behavioral invariants—transitions, exhaustiveness, state machine validity.

Third, simplicity beats features. Tagix has fewer features than Redux or other libraries. But the features it has are well-integrated. Every abstraction builds on the previous ones.

Fourth, documentation matters. Building a library is only half the work. Explaining how to use it, showing patterns, providing examples—that's where the real challenge lies.

Where Tagix Fits

Tagix is an experiment. It works best when:

Your application has clear state modes (loading/success/error, authenticated/unauthenticated)
You want TypeScript to catch bugs at the type-checking stage
You're willing to think about state transitions explicitly
Your team appreciates type safety

Tagix isn't right for every project. If you have simple state (toggle a boolean, store a single object), a simpler solution might be better. If you're working with legacy codebases, migrating to a tagged union model might be costly.

But for new applications where state complexity is high and correctness matters, Tagix offers a different way of thinking about state management.

The Road Ahead

Tagix is still young. Here's what's coming:

Better React integration with hooks
A DevTools extension for debugging
Middleware plugins for common patterns
More examples and documentation

But the core idea won't change. State as tagged unions. Actions as transition functions. TypeScript as your partner in correctness.

A Note on Effuse

The Tagix documentation website itself is built with Effuse—another library I created. Effuse is a component-based UI library with fine-grained reactivity, no virtual DOM, and the same focus on type inference that Tagix has.

I built Effuse because I wanted the Tagix documentation to demonstrate the library in action. Using two experimental libraries together has been instructive—both in showing what's possible and in identifying pain points that needed addressing.

If you're interested in component-based UI development with a different philosophy than React or Vue, check out Effuse as well.

Trying Tagix

The documentation is at tagix-docs.vercel.app. The source code is on GitHub at github.com/chrismichaelps/tagix.

There's a getting started guide, API documentation, and examples. I hope you'll give it a try and let me know what you think.

State management is hard. Tagix won't make it easy, but it might make it safer. And that's worth something.

Links:

Source code: https://github.com/chrismichaelps/tagix
Documentation: https://tagix-docs.vercel.app/
Effuse (library used to build the docs): https://github.com/chrismichaelps/effuse

Introducing Effuse — an experimental reactive framework

Chris M. Pérez — Mon, 12 Jan 2026 23:27:20 +0000

I built Effuse as a lightweight, reactive UI library designed for building modern web interfaces with a focus on simplicity and composability. My goal was to create a framework that prioritizes fine-grained reactivity through Signals, providing a familiar developer experience without the inherent complexity of a Virtual DOM.

import { define, signal } from '@effuse/core'

const Container = define({
  script: () => {
    const name = signal('World')
    return { name }
  },

  template: ({ name }) => (
    <div>
      <h1>Hello {name}!</h1>
      <p>Welcome to Effuse</p>
    </div>
  )
})

export default Container

A Powerful Internal Engine

One of the most important technical choices I made was to power Effuse internally with the Effect library. I use Effect to make side effects and asynchronous flows more predictable and expressive.

However, I want to emphasize that Effect is used strictly under the hood. I have designed the public API to be 100% Vanilla TypeScript, so you do not need to learn Effect or manage its complex return types to use Effuse. You get all the stability and performance of a functional engine while writing standard, clean TypeScript code.

A Comprehensive Ecosystem

I have expanded Effuse into a suite of specialized packages to handle different aspects of modern web development:

• @effuse/core: My core reactivity engine and DOM rendering system.
• @effuse/compiler: An optimized JSX/TSX transformer I developed to handle reactive signal access automatically, reducing boilerplate.
• @effuse/router: A simple, type-safe router for SPA navigation.
• @effuse/store: A functional state management library based on Effect.
• @effuse/query: A library for reactive data fetching with built-in reliability.
• @effuse/ink: A reactive Markdown renderer with support for embedded components.

Project Status & Vision

I want to be clear that Effuse is currently an experimental project driven by my own learning and exploration. It is not intended to compete with or replace established frameworks like React, Vue, or Solid. Instead, it is my personal space to experiment with new APIs and reactive patterns.

Because the project is still in development, it is not yet ready for production use. I am primarily looking for thoughts and feedback from developers who enjoy poking around experimental projects and exploring different approaches to UI development.

If you find my work interesting, please consider supporting the project with a ⭐ on GitHub!

GitHub: https://github.com/chrismichaelps/effuse
Docs: https://effuse-doc.vercel.app/

DEV Community: Chris M. Pérez

Pudu Programming Language

Why Pudu?

What Pudu looks like

Making failure visible

Expression-oriented by design

A language is more than its syntax

Building the implementation in Haskell

Compiler diagnostics matter

Why the name Pudu?

Where Pudu actually stands today

Where I want to take it

What building Pudu has taught me

The road to 0.1

This is only the beginning

Why I Built ACP: A Coordination Platform for Autonomous Coding Agents

Beyond Prompt Engineering: Why Your AI Architecture Is Leaking Tokens (And How to Fix It with FMCF)

1. The Core Constraint: Second-Order Markov Determinism

2. The Dual-Track Registry: Planning Before Building

The local.map.json / .index.json (Dynamic Topology)

3. The Cache Trust Protocol: Eliminating Stale State

4. Fixing Errors: Active Grammar Shards

The grammar/[lang].hash.md (Linguistic DNA)

5. The Forensic Audit: Keeping the AI Honest

The .chronos.json (Forensic Ledger)

6. The Power of Model Sinergy

Why This Matters for All Developers

Tagix: My Experimental State Management Library

Tagix: My Experimental State Management Library

The Problem I Was Trying to Solve

My Core Insight

Why Pattern Matching Matters

The Core Abstractions

Tagged Enum

Actions

The Store

Async Actions

Designing State Machines

Error Handling Patterns

Combining State Machines

Parallel State Machines

Nested State Machines

Performance Considerations

Selective Subscriptions

Memoization with Selectors

Common Patterns

Initialization Actions

Optimistic Updates

Undo/Redo

Testing Strategies

A Honest Note About Scope

The Design Decisions

Decision 1: No Action Types as Strings

Decision 2: Actions Return State Directly

Decision 3: Exhaustive Pattern Matching

What I Learned

Where Tagix Fits

The Road Ahead

A Note on Effuse

Trying Tagix

Introducing Effuse — an experimental reactive framework

A Powerful Internal Engine

A Comprehensive Ecosystem

Project Status & Vision

The `local.map.json` / `.index.json` (Dynamic Topology)

The `grammar/[lang].hash.md` (Linguistic DNA)

The `.chronos.json` (Forensic Ledger)