62 lines
1.5 KiB
Markdown
62 lines
1.5 KiB
Markdown
# Haskell State
|
|
|
|
This note covers `25-haskell-state/`, which plans a sequence of deployments by threading a build counter and per-environment wave numbers through
|
|
`State`.
|
|
|
|
---
|
|
|
|
## 1. What the State Represents
|
|
|
|
The planner keeps two changing values:
|
|
|
|
- the next global build number, and
|
|
- the next rollout wave number for each environment.
|
|
|
|
That is a good fit for `State`, because each planned deployment needs to read the current values and write back updated ones.
|
|
|
|
---
|
|
|
|
## 2. Why This Stays Pure
|
|
|
|
The planning logic does not perform I/O. It just transforms a list of deployment requests into a list of planned deployments.
|
|
|
|
`State` keeps that transformation pure:
|
|
|
|
```haskell
|
|
planDeployment :: DeploymentRequest -> State PlannerState PlannedDeployment
|
|
```
|
|
|
|
The caller still gets a plain value at the end through `evalState`.
|
|
|
|
That is the important intermediate Haskell idea here: stateful logic does not have to mean mutable variables or `IO`.
|
|
|
|
---
|
|
|
|
## 3. What the Example Allocates
|
|
|
|
Each request receives:
|
|
|
|
- a build number that increments globally, and
|
|
- a wave number that increments separately per environment.
|
|
|
|
That makes the output more interesting than a single counter example, while still teaching one concept.
|
|
|
|
---
|
|
|
|
## 4. Commands to Try
|
|
|
|
```bash
|
|
cd 25-haskell-state
|
|
|
|
nix develop
|
|
cabal run
|
|
cabal run -- api:production:3 worker:staging:1 cache:production:2
|
|
cabal test
|
|
|
|
nix build
|
|
./result/bin/mini-state-planner api:production:3 worker:staging:1 cache:production:2
|
|
|
|
nix run . -- api:production:3 worker:staging:1 cache:production:2
|
|
nix flake check
|
|
```
|