Then came the overall score:

Total FP Quality Index: 77/100

A score of 77 is good, but it is not 100. Seeing that number made me think: where did the missing 23 points go?

Standard linters operate on source text or surface syntax. A quick grep can spot a stray for loop, but it cannot tell you that a function returns maybe<maybe<T>>. That double wrapper forces callers to unwrap twice, turning None and Some(None) into two distinct states that callers are forced to distinguish.

Because hica runs right after the type checker, it operates on a fully-typed AST. It catches architectural design traps rather than cosmetic formatting:

fun find_first(pred: (int) -> bool, xs: list<int>) : maybe<maybe<int>> {
  Some(filter(xs, pred) |> head)
}

Here, head already returns maybe<int>. Wrapping it in Some(...) is redundant and turns the function signature into a trap. The fix is a single line:

fun find_first(pred: (int) -> bool, xs: list<int>) : maybe<int> =>
  filter(xs, pred) |> head

The typed AST also unlocks deeper analysis through Koka’s effect system. The analyser knows when a function looks pure on the surface but is not. A calculate_total function hiding a print statement inside an order-summing loop is detectable not from the source text, but directly from the effect row in the type tree. The guidance remains consistent: push I/O to the boundaries and keep core logic pure.

When tackling a larger codebase, filtering for the worst offenders yields the best return:

hica analyse my_program.hc --format markdown --top 3

This dumps a structured payload for the three lowest-scoring functions: signature, location, debt score, flagged anti-patterns, and the original snippet.

This format works well as a prompt payload for an LLM. Providing a report that specifies line numbers, scores, and flagged anti-patterns gives the model explicit constraints. You get targeted rewrites instead of vague suggestions.

In practice, the score alone is usually enough. Seeing [CRITICAL] my_program.hc:12 (score: 18) next to code written yesterday provides immediate clarity. Once a tool pinpoints the exact line and underlying flaw, fixing it directly is often faster than delegating it.

A score simply highlights where friction exists in your codebase. Whether you fix accidental debt or accept intentional trade-offs is still up to you.

Quick reference

hica analyse <file>                           # text report (terminal colours)
hica analyse <file> --format markdown         # markdown payload
hica analyse <file> --format markdown --top 5 # top 5 issues only
hica analyse .      --document                # generate project docs
hica analyse .      --document --check-docs   # verify docs are in sync

These two ideas are closely related. Generative AI amplifies both problems simultaneously.

I call this the double trap.

AI has dramatically reduced the cost of producing software. Individual developers can now generate code, tests, documentation, and even architectural proposals in minutes. Production has accelerated, yet our ability to validate and understand those changes has not. Learning is becoming the new bottleneck.

The result is a dangerous imbalance. We produce software faster than we can validate it, and we rely heavily on AI while understanding our systems less.

The two traps

The double trap emerges when two reinforcing forces feed into each other.

Trap 1: Faster output, slower feedback

DevOps has always been about shortening feedback loops. AI changes the economics of production while leaving the downstream constraints completely intact. Customer validation, testing, operational feedback, and organisational learning all still take the same amount of time.

Using AI to generate more code within the same delivery model only moves the bottleneck. More code creates larger queues that delay feedback. Ultimately, the system becomes much busier without actually becoming more effective.

This is the exact pattern behind the Pull Request Trap. When every developer can generate dramatically more code, asynchronous review queues become completely overwhelmed. The bottleneck shifts downstream, where changes sit waiting to be reviewed, integrated, tested, or understood. AI compresses production time, while feedback remains constrained by human speed.

AI optimises the productivity of individual developers. Organisations succeed by optimising the performance of the entire delivery system. Those are not the same thing.

Trap 2: Less thinking, less understanding

At the same time, AI fundamentally alters how we solve problems. When developers repeatedly outsource reasoning to an assistant, they make fewer architectural decisions themselves. They find themselves evaluating more than they create, and over time, their internal mental models weaken.

True comprehension is built through decision-making. We understand systems by exploring trade-offs, debugging failures, and explaining why one solution is better than another. If AI performs the bulk of that cognitive work for us, we gradually lose the intuition that makes experienced engineers valuable.

The real risk is perfectly correct-looking code that nobody in the team truly understands.

Why these traps reinforce each other

These two problems create a vicious reinforcing loop. Faster code generation increases the sheer volume of work entering the system, leading to longer queues and delayed feedback. As feedback slows down, so does learning.

This reduced understanding makes teams depend even more heavily on AI to explain, generate, and modify the codebase, which in turn generates even more output. The entire system accelerates while the underlying organisational capability slowly declines. Teams become busier while learning less.

Escaping the double trap

To escape this loop, we have to improve the systems we work in.

Build to learn before you build to earn

Use AI aggressively during product discovery. Prototype quickly, challenge assumptions, explore alternatives, and validate customer problems before investing heavily in production-quality software. Speed is most valuable when you are in the phase of learning.

Optimise feedback, not output

Practices like small batches, continuous integration, automated verification, and rapid deployment reduce the time between making a change and learning whether it was the right one. AI makes these practices even more essential.

Keep humans responsible for understanding

Use AI to generate options, not ownership. Every significant design decision must still be understood, challenged, and explained by the team responsible for operating the system. If you cannot explain why a solution works, you do not really own it.

Measure learning

Counting lines of code or completed tickets was never a good measure of progress. In an AI-assisted world, it is completely meaningless. Instead, optimise for customer feedback, deployment frequency, lead time, recovery time, and validated outcomes. These are the true signals that the organisation is learning.

Velocity isn’t the goal

AI dramatically accelerates software production, yet organisations still improve in the same fundamental ways. High-performing teams have always won by learning faster than everyone else. DevOps, Lean, and Trunk-Based Development all exist to shorten the feedback loops that make learning possible.

Velocity has never been the goal, learning has. Organisations that pair AI with fast feedback, small batches, continuous integration, and deep technical ownership will increase both their delivery speed and their overall capability. Those that optimise for output alone will fall straight into the double trap: producing more, while understanding less.

Tools like cURL are indispensable, but making routine JSON requests requires verbose flag ceremony (-H "Content-Type: application/json" -d '...'). HTTPie solved this years ago with intuitive syntax sugar, but running a Python interpreter on every invocation introduces noticeable startup latency. Curlie wrapped curl in Go to improve performance, but still requires external tools like jq to parse basic response payloads.

I wanted a single, fast native binary that combined the ergonomics of HTTPie, the rock-solid networking of libcurl, and native response filtering without needing jq.

The result is hicurl: a modern HTTP CLI built in hica.

What it does

hicurl handles the common HTTP operations without you having to fight shell quote escaping or pipe output to secondary tools.

Intuitive Syntax Sugar

Positional arguments are dynamically parsed into headers, query parameters, or JSON fields based on their operator:

# Implicit GET with query params
hicurl /search query=="hica lang" limit==10

# Explicit POST with typed JSON body and custom headers
hicurl post /users name="Alicia" age:=28 X-Client-ID:12345

# Localhost shorthand (expands to http://localhost:8000/v1/health)
hicurl :8000/v1/health :status

# Form data toggle (-f)
hicurl post /oauth/token name="Alicia" age:=15 -f

It also supports embedding files directly into request payloads: bio=@text.txt embeds file contents as a string, while data:=@payload.json parses and embeds the JSON structure directly.

Native Response Filtering

Instead of piping responses to jq, awk, or cut, response selectors can be appended directly to the query:

• JSON Dot-Paths: Extract nested fields or array elements directly (.data.users0.id).
• HTTP Metadata: Extract status codes (:status), raw headers (:headers), or specific case-insensitive header values (:header.Content-Type).
• Cookies & Diagnostics: Extract session tokens (:cookie.session_id) or query latency metrics directly from libcurl (:time, :time.ttfb, :time.dns).

Environment Contexts & Safety

When given a relative path like hicurl /v1/users -e staging, hicurl locates .hicurl.env by walking up parent directories (matching git directory resolution) and prepends the configured base URL.

It also includes an offline dry-run mode (--dry-run or -E http), which formats and prints the exact HTTP/1.1 request stream without firing bytes across the network. Safe inspection of request payloads is a core safety feature, reflecting the same philosophy behind tbdflow’s –dry-run feature.

TTY Awareness

One design rule hicurl follows is stdout TTY awareness.

When you run hicurl in an interactive terminal, JSON responses are pretty-printed and colourised with ANSI terminal colours for visual readability.

However, when stdout is redirected, piped to another command, or used in subshells, hicurl automatically suppresses all ANSI colour codes and formatting. If you query a dot-path like .token, it outputs the raw, unquoted string.

This makes command composition very clean:

# Query the GitHub API, pass the URL into a second hicurl query, and extract the bio
hicurl $(hicurl [api.github.com/search/users](https://api.github.com/search/users) q==cladam per_page==3 .items.0.url) .bio

What this means for hica

Building hicurl provided a practical testbed for std/cli, parent directory file operations, and C FFI bindings to libcurl.

Building CLI tools continues to be one of the best way to validate hica’s standard library and language mechanics. The C FFI story works, linking against system libcurl works cleanly, and the resulting binary runs without runtime overhead.

Try it

Using curl:

curl -fsSL https://github.com/cladam/hicurl/releases/latest/download/install.sh | sh

Or using hicurl (leveraging implicit GET, redirect following, and TTY detection to stream raw text to sh):

hicurl https://github.com/cladam/hicurl/releases/latest/download/install.sh | sh

Pre-built binaries are available for macOS (ARM64), Linux (ARM64, x86_64) and Windows (x86_64).

• hicurl source - MIT licensed
• hica - the language it’s written in

Instant feedback loops are a safety feature!

This is where the REPL shines.

Instead of just running the files in the examples/ directory as static binaries, you can load them directly into hica’s REPL. This lets you inspect their types, call functions with different arguments, and even write new helpers on top of them interactively.

This post walks through how to explore hica examples in the REPL and how Hindley-Milner type inference makes interactive learning a lot faster.

Querying types on the fly

Because hica uses Hindley-Milner type inference, the compiler always knows the types even if you didn’t write them down. When you load an example into the REPL, you don’t need to guess what arguments a function takes or go digging through the source code. You can just ask the compiler.

With the :t command, you can query any function or expression:

hica=> :t fizzbuzz
  (n: int) : string

This tells you the exact signature of fizzbuzz. You get instant feedback without having to run the code or look at the files.

A typical session

To start exploring, run the REPL from the root of the project:

hica repl

You can load any example using :load. The REPL will parse and type-check the file:

hica=> :load examples/fizzbuzz.hc
  loading examples/fizzbuzz.hc
  loaded: fizzbuzz

If you want to see what functions were loaded, use :defs:

hica=> :defs
  fun fizzbuzz(n)

Now check the type of fizzbuzz:

hica=> :t fizzbuzz
  (n: int) : string

Once loaded, you can evaluate expressions directly:

hica=> fizzbuzz(15)
"FizzBuzz"
hica=> fizzbuzz(7)
"7"

You can also define new functions on top of what is already loaded. For example, we can write a helper to run fizzbuzz over a range of numbers:

hica=> fun fizz_range(lo, hi) { [lo..=hi] |> map(fizzbuzz) }
  defined: fizz_range

And run it:

hica=> fizz_range(1, 15)
["1", "2", "Fizz", "4", "Buzz", "Fizz", "7", "8", "Fizz", "Buzz", "11", "Fizz", "13", "14", "FizzBuzz"]

If you want to switch to a different example, there is no need to restart the REPL. Just reset the state and load another file:

hica=> :reset
  state cleared
hica=> :load examples/word_count.hc
  loading examples/word_count.hc
  loaded: count_words, show_entry

Useful commands

Here is a quick reference of the available commands:

:load <file>     # Load a hica source file
:defs            # List all active functions, structs, and enums
:t <expr>        # Show the inferred type of an expression
:reset           # Clear the active environment
:help            # Show all commands
:quit            # Exit the REPL

Suggested progression

If you want to explore the examples, this is a good order to go through:

1. examples/fizzbuzz.hc: Basic control flow, conditionals, and integers.
2. examples/word_count.hc: List pattern matching, recursion, and string manipulation.
3. examples/json_parser.hc: Custom enums (ADTs), tuple usage, and parser states.

Have fun exploring!

Feedback loops are the ultimate learning accelerant.

tbdflow needed structured JSON output first, otherwise IPC would have meant brittle string parsing. Adding --json also improved the overall developer experience: if you use tbdflow in scripts or have a Genie committing code through it, you get machine-readable output instead of human-readable text. Supported by info, status, radar, sync, recover --list, task show, and note --show.

The commands work great in the terminal. But sometimes you just want to glance at a repository’s health without switching context, a quick ambient read. That peripheral awareness is important for comprehension, especially across multiple repos (teams should really be on a monorepo, but that’s a separate post).

The result is tbdflow-ui: a persistent three-panel desktop window that sits alongside your editor and keeps the workflow visible.

What it does

The window is organised into three panels.

The left panel is your context: which repo you’re in, which branch, whether CI is enabled, whether radar is active. A quick glance tells you where you are and whether the trunk is healthy.

The centre panel is where the work happens. Sync with one click. The Intent Log is right in front: type a note, press Add Note, it calls tbdflow note "<text>" and the log refreshes immediately. The breadcrumb is the point: reasoning is sharpest at the moment you write the code, and a field sitting in front of you captures it before the next context switch. Rules that rely on documenting something later don’t have the same pull. I wrote about the underlying risk in The Comprehension Crisis. Below that is the commit form: a type dropdown populated from your repo’s tbdflow --json info config and a message. There is an Advanced toggle for the rest of the supported options.

The right panel provides Awareness: trunk status with a colour-coded signal (green, pending, red), churn hotspots from the last three days highlighted on a red-to-yellow scale, and an overlap count across active branches.

It also supports multiple repos. Click Browse, pick a directory, all panels reload. Handy if you’re switching between a few repos throughout the day.

The design rule

There’s one rule the UI follows strictly: the CLI is the source of truth.

tbdflow-ui never touches Git directly. Every piece of data comes from tbdflow --json <command>. The commit button constructs a full tbdflow commit -t <type> -m "<message>" command string and executes it. The intent log reads from tbdflow --json notes. Radar reads from tbdflow --json radar.

This matters because it means the UI can never drift out of sync with the CLI’s logic. If tbdflow adds a new commit flag tomorrow, the UI gets it by passing through the JSON output, not by reimplementing the logic.

Why a desktop app?

A terminal is perfect when you’re actively working. A desktop window serves a different purpose. It provides ambient awareness: trunk health, overlaps, hotspots, and your current intent are visible without interrupting your flow. The goal wasn’t to replace the CLI, but to complement it.

Built with hica

This is the part that interests me most, because tbdflow-ui is written in hica, my own functional, expression-based language.

hica transpiles to Koka, and Koka compiles to C. So the pipeline for tbdflow-ui is:

.hc → hica → .kk → Koka → C → native binary

For a CLI tool, that pipeline is fairly unremarkable. For a GUI app with Dear ImGui, it gets more interesting. ImGui is a C++ immediate-mode GUI library. Getting hica to talk to it meant building a thin C FFI layer that exposes ImGui’s widgets as plain C functions, then wrapping those in a hica imgui library.

The result is that the hica source looks like this:

fun render_sidebar_context(c: Config, s: Status) {
  label("Branch")
  gui_text(s.current_branch)
  gui_spacing()

  label("Mode")
  gui_text(c.mode)
  gui_spacing()

  label("CI Status:")
  gui_same_line()
  if c.ci_check_enabled {
    gui_text_colored("- Enabled", 0.06, 0.71, 0.65, 1.0)
  } else {
    gui_text_colored("o Disabled", 0.94, 0.33, 0.31, 1.0)
  }
}

No FFI boilerplate in application code. No pointer management, no widget IDs, no frame-begin/frame-end ceremony. hica’s effect system means the rendering context flows implicitly; IO effects are tracked at the type level without being specified on every function.

The commit command builder is a good example of how hica code reads. It’s purely functional: a chain of string conditionals that assembles the final shell command:

pub fun build_commit_cmd(ctype: string, msg: string, scope: string, body: string, 
                         tag: string, issue: string, breaking: bool, no_verify: bool) {
  let base = "tbdflow commit -t " + ctype + " -m \"" + msg + "\""
  let s1 = if scope != ""   { base + " -s " + scope }             else { base }
  let s2 = if body  != ""   { s1   + " --body \"" + body + "\"" } else { s1 }
  let s3 = if tag   != ""   { s2   + " --tag " + tag }            else { s2 }
  let s4 = if issue != ""   { s3   + " --issue " + issue }        else { s3 }
  let s5 = if breaking      { s4   + " --breaking" }              else { s4 }
  let s6 = if no_verify     { s5   + " --no-verify" }             else { s5 }
  s6
}

Pure functions with clear data flow and no side effects until exec() is called.

The hica imgui library

One thing I really like is the theming. Since the entire rendering surface is a hica module, I can write themes as plain hica files:

pub fun apply_theme() {
  gui_set_color_text(0.9333, 0.9411, 0.9529)
  gui_set_color_bg(0.0941, 0.1098, 0.1451)
  gui_set_color_accent(0.2314, 0.5098, 0.9647)
  gui_set_color_plot(0.0588, 0.7098, 0.6549)
  gui_set_style_rounding(4.0, 4.0, 4.0)
  gui_set_style_spacing(8.0, 6.0, 16.0)
}

Drop a different theme file in, call a different function. The app ships with a “Stillness Dark / Nordic Blue” theme and a One Dark Pro theme. Switching is one function call. The imgui library has a theme-editor if you want to create your own themes.

What this means for hica

tbdflow-ui is the most complete application I’ve built with hica so far, and hica itself didn’t require any language changes to build it. The language was already capable. What did evolve was the imgui FFI library: tbdflow-ui had requirements the earlier layer didn’t cover, so those gaps got filled as the application needed them.

That’s a healthy feedback loop. A real program with real requirements is a better driver for a library than designing the API in the abstract.

The takeaway is that hica can build real desktop GUI applications. A tool with multiple data sources, reactive panels, live CLI integration, clipboard access, hyperlinks, and two polished themes. The C FFI story works. The linking story works (Koka link flags for C++ static libs with --cclinkopts=-lc++). It compiles to a single native binary.

Try it

curl -fsSL https://github.com/cladam/tbdflow-ui/releases/latest/download/install.sh | sh

Pre-built for macOS ARM64 and Linux x86_64. Requires tbdflow v0.33.0+ and SDL2 on your system.

If you want to build from source, install hica and run hica run in the repo root.

• tbdflow-ui source - MIT licensed
• tbdflow - the CLI this wraps
• hica - the language it’s written in

This is an early release. tbdflow-ui will be improved continuously.

Throughput is a safety feature!

I find myself sceptical, and not because of the AI part.

A pattern that feels familiar

The workflow looks like this:

1. Design a large batch of features upfront.
2. Generate a large body of code from that design.
3. Review, test, and debug the output.
4. Ship it in a single release.

In DevOps, this is Big Batch Delivery. We have decades of evidence for why it struggles. Large batches amplify risk at every stage. A single flawed assumption early in the design doesn’t just invalidate one feature; it invalidates everything built on top of it.

Software requirements aren’t facts. They are a network of unverified hypotheses.

The entire purpose of iterative delivery is to test those hypotheses as cheaply and as early as possible, long before you have built an ecosystem on top of them.

AI doesn’t change this. The bottleneck was never how fast code gets written. It is the feedback loop.

The review problem

When an AI agent produces a large, multi-thousand-line output from a single specification, that code still has to be integrated, understood, and maintained by a human team. In practice, it lands in a review gate.

I explored this in The Pull Request Trap. Human comprehension doesn’t scale with line count. A team reviewing a two-thousand-line AI-generated diff faces the same cognitive limits as a team reviewing a two-thousand-line human-generated one. Under time pressure, reviews go superficial. The gate exists, but the signal is weak.

Slower integration is the obvious problem. The less obvious one is structural debt introduced without anyone understanding it well enough to manage it.

The comprehension dimension

There is also a subtler problem. When you optimise purely for generation speed, delivery and understanding come apart.

I wrote about this in The Comprehension Crisis. If a model generates the spec, the code, and the explanation, it is easy to ship without ever owning the reasoning behind it. The system looks faster but the team’s capability quietly degrades.

Human comprehension must scale with delivery, or ownership evaporates.

With large, spec-driven outputs, the team inherits a codebase they didn’t reason through. When something breaks, and it will, debugging starts from a much weaker position.

What Elephant Carpaccio teaches us

The practice of slicing work into the smallest provable unit has a name: Elephant Carpaccio. The goal isn’t smaller work for its own sake. It is to shorten the distance between a decision and its validation.

This doesn’t change when an AI is doing the coding. Fast generation only helps if you can confirm assumptions just as fast. That speed advantage disappears the moment you batch everything back up into a slow, uncertain release.

Some things stay true regardless of who writes the code:

• Feed the smallest useful slice to the agent. A tightly scoped prompt produces output that is easier to review, test, and validate in production.
• Prefer continuous integration over gates. Trunk-based development with non-blocking reviews keeps changes flowing and keeps comprehension distributed across the team.
• Treat telemetry as the ground truth. Real user behaviour, not the initial spec, is where value is confirmed or refuted.
• Throughput and comprehension are not in tension. High throughput with deep understanding lets you isolate variables and adapt quickly. High throughput without understanding is how you accumulate hidden debt.

The underlying question

Spec-Driven Development probably has a place: where requirements are stable, well-understood, and easy to verify in bulk. Most product work isn’t like that.

Writing a complete spec and getting a complete codebase back feels productive. Feeling productive and being productive are different things. If a core assumption in the spec is wrong, the cost scales with how much was built before anyone found out.

Micro-sized batches and tight feedback loops aren’t a constraint on what AI can do. They’re how you find out if what the agent produced was worth building.

Throughput is a safety feature!

A better-informed model beats a smarter one.

The idea

Ollama lets you create custom models with a Modelfile: base LLM, parameters, and a system prompt. That prompt is permanent context the model reads before every message.

hica-assistant is built on qwen3.6:35b-a3b (a mixture-of-experts model, fast on a Mac) with a system prompt covering the compiler pipeline, syntax rules, the prelude API with types, the stdlib, and a table of pitfalls from real bugs I’ve encountered during development.

ollama create hica-assistant -f Modelfile
ollama run hica-assistant

No API key needed, no data leaving the machine (works offline) and no rate limits.

The verify part

Every snippet the model generates gets checked with the hica compiler:

hica check generated.hc
hica run generated.hc
hica test generated.hc

When it fails, I find the gap in the Modelfile, add the rule, and rebuild. The system prompt is the ground truth and very updateable. My chat history is throwaway.

Let’s look at a concrete example: the model kept writing is_empty(list) to check whether a list is empty, that’s wrong as is_empty takes a string. I added a row to the pitfalls table, ran ollama create hica-assistant -f Modelfile, and the next response used match xs { [] => ... } correctly.

The loop: prompt, generate, compile, fix Modelfile, rebuild.

It works for real code

I asked it to write a filter-map-fold pipeline. First try, both styles:

fun main() {
  // pipe style
  let a = [1, 2, 3, 4, 5]
    |> filter((x) => x % 2 == 0)
    |> map((x) => x * 10)
    |> fold(0, (acc, x) => acc + x)
  println(a)   // 60

  // dot-call style, same result
  let b = [1, 2, 3, 4, 5]
    .filter((x) => x % 2 == 0)
    .map((x) => x * 10)
    .fold(0, (acc, x) => acc + x)
  println(b)   // 60
}

Both compile. Both produce 60. a |> f and a.f() are the same thing and the model knows when to reach for each.

Bounded knowledge is a feature

The model only knows what’s in the Modelfile. Ask it about get_cwd(), which doesn’t exist in hica yet, and it says so and gives the real workaround (get_env("PWD")). A generic model would invent get_cwd() confidently and leave you debugging a compile error.

When something is missing from the Modelfile, I add it. Right now it covers the prelude, std/io, std/list, std/datetime, and the main pitfall patterns. The file grows with the language.

The Modelfile is in the repo

The Modelfile is in the hica repo, Apache 2.0 licensed.

The approach works for any language, framework, or internal API a generic model hasn’t seen. Write down what it needs to know, verify with real tooling, iterate.

HiLisp is now live and ready for tinkering.

Why a Lisp?

Many developers write a Lisp at some point. Same thing here really.

The useful part is that maintaining HiLisp is hica development. Every script and example exercises the compiler and provides feedback. I ended up fixing several bugs in hica while building HiLisp.

The main inspiration was Carp, a Lisp with ML/Rust-like semantics. HiLisp borrows its vocabulary of special forms: defn, def, fn, let, do, cond, quote.

Also, there is objective beauty in parentheses.

What it looks like

(defn factorial (n)
  (if (<= n 1) 1 (* n (factorial (- n 1)))))

(println (factorial 10))   ; 3628800

Closures work:

(defn make_adder (n) (fn (x) (+ x n)))
(def add10 (make_adder 10))
(println (add10 32))   ; 42

And higher-order functions:

(defn map (f lst)
  (if (= lst '()) '()
    (cons (f (car lst)) (map f (cdr lst)))))

(println (map (fn (x) (* x x)) '(1 2 3 4 5)))
; (1 4 9 16 25)

The pipeline

HiLisp is a classic tree-walker interpreter:

source text → tokenise → parse → eval

Each phase lives in its own hica module: tokeniser.hc, parser.hc, eval.hc. The AST is a recursive LVal enum representing numbers, booleans, strings, symbols, lists, lambdas, and nil. Pattern matching over that enum drives the evaluator.

The interesting bit was environments. Each lambda captures a reference to its defining environment for proper lexical scoping. I expected that to need some gymnastics, but structs and recursive types in hica made it pretty straightforward.

Try it

./hilisp                         # REPL
./hilisp examples/recursion.hl   # run a file

# Build from source (needs hica ≥ 0.29.3 and Koka 3.2.3)
hica build -o hilisp

The examples/ folder contains runnable .hl files covering arithmetic, closures, recursion, lists, and sorting. There’s also a lib/prelude.hl with helpers like map, filter, and fold.

• Source, MIT license.
• Lisp primer, start here if you’ve never worked with a Lisp.

Going forward, I’ll definitely be using HiLisp as part of hica development itself, both as a playground and as a way to continuously exercise the compiler with real code.

Early on in hica’s design I wanted the simplest possible testing workflow, and I think I succeeded (IMHO)

This post walks through how TDD works in hica and why the compiler changes what you need to test.

TDD isn’t new

TDD has a reputation as a methodology someone invented. It’s most definitely not. Kent Beck has said he “rediscovered” it by studying older literature and watching what good programmers already did. Dijkstra argued in 1972 that correctness proof and programs should “grow hand in hand.”

Andrea Laforgia captures this well in his T*D piece. TDD, trunk-based development, and collaborative programming are patterns that keep emerging when teams care about quality and fast delivery. When you remove friction from testing, people test first. That’s what happened with hica.

The compiler does half the work

hica has Hindley-Milner inference and exhaustive pattern matching. A lot of the defensive tests I’d write in other languages aren’t needed:

type Direction {
  North, South, East, West
}

fun move(pos, dir) {
  match dir {
    North => (pos.0, pos.1 + 1),
    South => (pos.0, pos.1 - 1),
    East  => (pos.0 + 1, pos.1),
    West  => (pos.0 - 1, pos.1)
  }
}

Forget the null case (there’s no null). Pass a string where a Direction is expected? It won’t compile. Leave out West? Compile error. The type checker handles structural correctness. What’s left for tests is whether the function does the right thing.

Rule of thumb: if the compiler can’t distinguish a correct implementation from an incorrect one, write a test.

Red-green-refactor

Let’s build a simple password validator from scratch.

Red. Stub the interface, assert what you want:

fun validate(password) => false

test "valid password has 6+ characters" {
  assert(validate("secret123"))
}

hica test password.hc fails. Good, that’s expected.

Green. Minimum code to pass:

fun validate(password) => str_length(password) >= 6

Passes.

Red again. New requirement: passwords need at least one digit. Add a test for it. It should fail against the current validate implementation:

test "rejects password without digit" {
  assert_false(validate("noNumbersHere"))
}

Green. Update the implementation to pass all tests:

fun has_digit(s) => any(chars(s), (c) => is_digit(c))

fun validate(password) {
  let long_enough = str_length(password) >= 6
  long_enough && has_digit(password)
}

test "valid password has 6+ characters" {
  assert(validate("secret123"))
}

test "rejects password without digit" {
  assert_false(validate("noNumbersHere"))
}

test "rejects short password" {
  assert_false(validate("ab1"))
}

All three pass. Refactor whenever, the tests catch regressions.

No context switch

Tests live next to the code:

fun double(x) => x * 2

test "double works" {
  assert_eq(double(3), 6)
  assert_eq(double(0), 0)
}

running 1 test(s)...

  ✓ double works

1 test(s) passed

When something breaks:

  ✗ double works
    assertion failed: assert_eq(double(3), 5)
      expected: 5
      actually: 6

Use assert_eq over assert. “expected 5, got 6” tells you what happened, assert just says “false”.

A typical session

hica repl                # explore an API before writing tests
nvim password.hc         # write a failing test
hica test password.hc    # see it fail
nvim password.hc         # make it pass
hica test password.hc    # see it pass
hica check password.hc   # fast type-check between edits
tbdflow commit -t feat -m "add password validation"

hica check only type-checks, no compilation and near instant. I run it between almost every edit, like a spellchecker for logic 🙂 hica repl is useful when you’re not sure what a function returns. Try it interactively first, then write the test.

One test per behaviour

“Validates length” and “requires digit” are separate tests. If a test name needs “and” in it, split it.

Happy testing!

Throughput is a safety feature! (now with tests)

The itch

hica is a statically typed, expression-oriented language. It compiles .hc source files through a Pratt parser and Hindley-Milner type checker, emits Koka .kk source, and lets Koka handle the rest.

I’ve wanted to design my own language for years. Every attempt fizzled out in the same place: the plumbing… Lexers, type systems, backends, memory management – the mountain of infrastructure you need before you can even think about syntax. It felt like building a house by first inventing concrete in a way…

But then it occurred to me, if I target Koka, I skip all those parts. Koka already has Perceus for memory, C/JS/WASM backends, a standard library, optimisation passes, and the effect runtime. I just need to build the front half: syntax, type checker, diagnostics, and an emitter that spits out .kk files. Koka handles the rest.

The constraint is that hica can only express what Koka can express, but given that hica’s design pillars (algebraic effects, Perceus memory, expression-oriented, strong inference) are exactly what Koka already provides, that costs almost nothing.

What it looks like

fun fizzbuzz(n) =>
  if n % 15 == 0 { "fizzbuzz" }
  else if n % 3 == 0 { "fizz" }
  else if n % 5 == 0 { "buzz" }
  else { "{n}" }

fun main() {
  for i in 1..100 {
    println(fizzbuzz(i))
  }
}

Everything is an expression: if, match, blocks all return values. No return keyword. "{n}" is string interpolation. The name stands for Hindley-milner Inference Compiler with Algebraic effects.

The pipeline is straightforward:

.hc source → Lex → Parse → Desugar → Type Check → Emit Koka (.kk) → Koka Compiler → C/JS/WASM

Each compiler phase uses algebraic effects for its state: diagnostics, type variables and symbol scopes are all effect-tracked. Compilers in Koka are surprisingly natural. The type checker runs Hindley-Milner unification and the emitter annotates the Koka output with the inferred types.

The tooling

I really enjoy building CLI tools, hica comes with hica run, hica build, hica check (which reports effects!), hica test, hica fmt, hica new, hica clean. The CLI is using my Clap inspired klap library, which handles flags, subcommands, and help generation.

I needed to test hica properly and have reused kunit to validate and verify its functionality, hundreds of tests across lexer, parser, checker, codegen, and CLI.

Built with help of a Genie

I used a Genie (what I call my GenAI model – thanks Kent Beck for the term) as a pair-programming partner throughout. I maintain the backlog and iterate until it’s right. It lets me focus on the design decisions; the Genie handles the mechanical parts. It’s been superfun, and a breath of fresh air compared to grinding through boilerplate alone.

Try it

The language is fun to use, and really usable with structs, enums, full pattern matching, modules, closures, UFCS, built-in testing.

I have tried to document along the way, and to be honest, I think I did a good job with it, take a look:

• Playground: try hica in the browser, no installation needed.
• Docs: language reference, quick start, and style guide.
• Source: Apache-2.0 licensed.

Thank you, Koka

hica wouldn’t exist without Koka. The effect system, Perceus, the C backend is all inherited. Huge thanks to everyone working on Koka for making it possible for someone like me to build a real language.