# Haskell Dependency Order

This note covers `34-haskell-dependency-order/`, which computes a deployment order from service dependencies and rejects cycles.

---

## 1. What the Planner Has to Do

For each requested service, the planner needs to:

- find its dependencies,
- visit those dependencies first,
- avoid emitting the same service twice, and
- reject cycles and unknown names.

That makes the example a good fit for a graph-style traversal, even though the code stays small and explicit.

---

## 2. Why the Output Order Matters

The planner emits `DeploymentStep` values in dependency order.

That means infrastructure and foundational services appear before dependents such as `api`, `billing`, or `frontend`.

This is the important behavior the example demonstrates: ordering is part of correctness, not just presentation.

---

## 3. Why the Cycle Check Is Separate

The example tracks both:

- services currently being visited, and
- services already resolved.

That distinction is what lets it detect `a -> b -> a` style cycles without falsely rejecting shared dependencies that are reached more than once.

---

## 4. Commands to Try

```bash
cd 34-haskell-dependency-order

nix develop
cabal run
cabal run -- frontend billing
cabal test

nix build
./result/bin/mini-dependency-order frontend billing

nix run . -- frontend billing
nix flake check
```