REPL-Driven Flight Tracking

The contract verifier diffs canonical output across sources:

(def contract-keys [:ident :registration :status :gate_destination :estimated_in])

;; Callsign normalization: BA48 ≡ BAW48 ≡ BAW48Q
(defn normalize-ident [s]
  (cond
    (re-matches #"[A-Z]{2}\d+.*" s)
    (str ({"BA" "BAW" "AA" "AAL" "DL" "DAL"} (subs s 0 2)) (subs s 2))
    :else s))

A key finding: the gate_origin field is visible on the FlightAware website before it appears in the API. This is eventual consistency with a visible convergence lag — the web frontend reads from a different replica (or cache layer) than the API.

Filed route: KSEA ALPSE YDC → oceanic fixes → JELCO GRIBS KETLA → Greenland crossing → NUGRA2H STAR → EGLL

The route passes through Davis Strait (~60-63°N) where terrestrial ADS-B coverage transitions to space-based surveillance (Aireon). The update_type field in AeroAPI track positions encodes this:

A naive tracker reports "gap" when surveillance source changes. A correct tracker reports "handoff."

Analysis of 658 track positions from the 2026-05-17 departure showed all positions as type A (ADS-B) or Z (radar) — no S (space-based). This suggests either continuous terrestrial ADS-B coverage on this routing or that AeroAPI's Personal tier does not surface the S distinction. An open question for further investigation.

At 22:00 UTC (6 PM ET), ADS-B message volume dropped 37% — from 141,751 to 88,880 messages/hour. Not receiver failure; aircraft absence. This drop occurred 30 minutes after the first FAA ground stop (see FAA correlation below).

This analysis was not planned. It emerged step by step — each evaluation informed the next hypothesis.

;; STEP 1: Load and count
(def storm-data (load-data "2026-05-19" [21 22 23]))
(count storm-data)
;; => 352,003 messages in 3 hours

;; STEP 2: Message type distribution
(->> storm-data (map :msg-type) frequencies)
;; => {"3" 27782, "4" 39241, "7" 205789, "8" 68109}
;; MSG,3 = positions, MSG,1 = callsigns

;; STEP 3: Correlate callsigns to positions via ICAO hex
(def icao->cs (build-callsign-map storm-data))
;; => 203 unique aircraft

;; STEP 4: Hypothesis — are aircraft holding?
(def by-icao (group-by :icao (filter :lat storm-data)))

;; STEP 5: Calculate geographic spread per aircraft
(defn spread-nm [positions]
  (let [lats (map :lat positions)
        lons (map :lon positions)]
    (apply max (map #(haversine-nm (mean lats) (mean lons) (:lat %) (:lon %))
                    positions))))

;; STEP 6: The threshold wasn't known until step 5 revealed the distribution
(->> by-icao
     (map (fn [[icao ps]]
            {:callsign (get icao->cs icao icao)
             :positions (count ps)
             :spread (spread-nm ps)
             :alt-range (- (apply max (keep :altitude ps))
                           (apply min (keep :altitude ps)))}))
     (filter #(< (:spread %) 15))
     (filter #(< (:alt-range %) 3000))
     (sort-by :positions >)
     (take 10))
;; => JBU834 (347 pos, 13.5nm), AAL2595 (295, 11.3nm), SWR52 (261, 14.3nm)

The filter predicate at step 6 — < 15nm spread, < 3000ft altitude range — could not have been written in advance. The thresholds came from inspecting the distribution at step 5. This is the non-zero-shot argument: the analysis responds to its own output.

Position data revealed 56 aircraft in holding patterns northwest of Logan, centered on the BOSCO/ROBUC holding fixes at ~42.45°N, 71.08°W.

Swiss 52 reported 261 positions with only 25-foot altitude variance — textbook holding at assigned altitude.

102 aircraft descended through the 8,000 ft marker during the storm window. The approach band (5-12k ft) shows aircraft stacking up in holding patterns rather than completing their descents to the terminal area. Terminal operations (<5,000 ft) dropped 60%. Cruise traffic (>28,000 ft) continued unimpeded — the signature of a ground stop.

The FAA ATCSCC issued multiple advisories for BOS on May 19. The timeline shows our ADS-B data captured the effect of the ground stop, not a precursor:

The ADS-B message drop at 22:00Z occurred 30 minutes after the first ground stop (advisory 118 at 21:30Z). This is the expected propagation delay — departures stop, then airborne traffic clears.

Source: Advisory 160 — 3,277 total delay-minutes, ground congestion on taxiways after brief reopenings.

May 19 produced 167 ATCSCC advisories — nearly double the 90/day baseline. The chart shows it in context: a clear anomaly, though March 16 (216) was worse. Other airports also ground-stopped, but those are outside our receiver range.

Data sourced from Boston.com and NBC Boston:

Massport advisory: "Due to winter storm clean up, few airlines are operating at Logan today. Please check with your airline before coming to the airport."

The following APIs provide weather data for KBOS correlation:

For data older than 30 days (like January 2026), use the NCEI Archive Information Request System (AIRS). Select "Land-Based" → "Service Records Retention System (SRRS)" and request KBOS data for the date range. Results are emailed within ~30 minutes.

The following demonstrates fetching current KBOS weather via the NWS API. This same pattern works for historical analysis once data is retrieved from NCEI.

;; REPL session: 2026-05-23T19:45:00Z
;; Query NWS API for KBOS current observations

(require '[babashka.http-client :as http])
(require '[cheshire.core :as json])

;; Fetch latest observation
(def kbos-obs
  (-> (http/get "https://api.weather.gov/stations/KBOS/observations/latest"
                {:headers {"User-Agent" "flight-tracking/1.0"}})
      :body
      (json/parse-string true)))

;; Extract key fields
(def weather
  {:station (get-in kbos-obs [:properties :station])
   :timestamp (get-in kbos-obs [:properties :timestamp])
   :temperature-c (get-in kbos-obs [:properties :temperature :value])
   :wind-speed-kmh (get-in kbos-obs [:properties :windSpeed :value])
   :visibility-m (get-in kbos-obs [:properties :visibility :value])
   :description (get-in kbos-obs [:properties :textDescription])})

weather
;; => {:station "https://api.weather.gov/stations/KBOS"
;;     :timestamp "2026-05-23T23:45:00+00:00"
;;     :temperature-c 13
;;     :wind-speed-kmh 9.252
;;     :visibility-m 16093.44
;;     :description "Clear"}

The NWS API returns GeoJSON with nested properties. Key fields for flight impact assessment:

• visibility — below 1600m triggers IFR, affecting approach rates
• windSpeed / windDirection — crosswind limits vary by runway
• textDescription — human-readable conditions

For January 26 data, the Aviation Weather Center archive provides 30-day lookback. Beyond that, NCEI AIRS is required:

;; Fetch METAR from AWC archive (within 30 days)
(defn fetch-metar-archive [station date]
  (let [url (format "https://aviationweather.gov/api/data/metar?ids=%s&date=%s"
                    station date)]
    (-> (http/get url {:headers {"User-Agent" "flight-tracking/1.0"}})
        :body)))

;; For Jan 26 (>30 days old), we need NCEI AIRS
;; Submit request at: https://www.ncdc.noaa.gov/has/HAS.DsSelect
;; Select: Land-Based → SRRS Text Products
;; Station: KBOS, Date: 2026-01-26 to 2026-01-27

;; Once retrieved, parse the SRRS format:
(defn parse-metar-line [line]
  (let [[_ time wind vis wx temp dew altim]
        (re-matches #"KBOS (\d{6}Z) (\S+) (\S+) (\S*) (\S+)/(\S+) A(\d+)" line)]
    {:time time :wind wind :visibility vis :weather wx
     :temp temp :dewpoint dew :altimeter altim}))

;; Example METAR from Jan 26 blizzard:
;; KBOS 261456Z 02025G35KT 1/4SM +SN BLSN VV008 M04/M06 A2974
;; Wind 020 at 25 gusting 35kt, 1/4 mile vis, heavy snow, blowing snow

• ADS-B receiver archive availability for Jan 26-27 (not yet confirmed)
• NCEI SRRS data request pending — submit via AIRS for historical METAR
• If no ADS-B archive: this case study stays FAA + weather-only, demonstrating ground stop recovery from public data alone

Sources for this section:

• Boston.com: Flights delayed, cancelled at Logan Airport — 18.6" snow, 508 cancellations
• NBC Boston: Hundreds of flights canceled — 971 cancellations, runway status
• NWS API — current observations endpoint (verified working)
• AWC Archive — METAR/TAF up to 30 days
• NCEI AIRS — historical SRRS data request system

Do winter ground stops produce the same altitude-band signature as thunderstorms? The hypothesis: no. Winter operations keep aircraft on the ground (deicing, cancellations), so the approach band shouldn't show holding patterns. The REPL test:

;; If archives exist: compare altitude distributions
(def winter-bands (altitude-histogram (load-data "2026-01-26" (range 24))))
(def storm-bands  (altitude-histogram (load-data "2026-05-19" [21 22 23])))

;; Are the distributions different?
(chi-squared-test winter-bands storm-bands)

Source: FAA ATCSCC Advisories 2026-03-16

The hypothesis: if BOS wasn't ground-stopped, ADS-B message volume should be normal or slightly depressed — not the 37% drop seen on May 19. The REPL test:

;; Compare message volumes
(def mar16-volume (hourly-counts (load-data "2026-03-16" (range 24))))
(def may19-volume (hourly-counts (load-data "2026-05-19" (range 24))))
(def baseline    (hourly-counts (load-data "2026-05-15" (range 24))))

;; Normalize to baseline
(map (fn [h] {:hour h
              :mar16 (/ (get mar16-volume h 0) (get baseline h 1.0))
              :may19 (/ (get may19-volume h 0) (get baseline h 1.0))})
     (range 24))
;; Expected: mar16 ≈ 1.0, may19 << 1.0 in hours 21-23 UTC

The negative case strengthens the storm case study. If Mar 16 — a worse day by advisory count — shows normal ADS-B volume near BOS, then the May 19 drop is specifically attributable to the BOS ground stop, not to general NAS stress. Without the negative control, the May 19 analysis could be explained by "the whole system was busy."

• ADS-B archives for Mar 16 (not yet confirmed)
• The specific ZBW advisories on Mar 16 (route restrictions? flow constraints? not ground stops) — worth fetching for comparison
• If no ADS-B data: this case study demonstrates hypothesis formation from advisory data alone, with the REPL test as a specification of what we'd check

This case study is the model. When an agent works with a complex external system, the execution context of its code matters more than the code itself. Specifically:

• A bash subprocess loses cd on exit. The next CLI call starts in the parent shell's directory, not where you left off.
• A bash subprocess loses environment-variable mutations on exit. Set AEROAPI_KEY in one call; the next call needs it set again.
• Each bash -c '...' invocation is a fresh execution context. Any loaded data, parsed JSON, or computed intermediate is gone.
• Each bb -e '(...)' invocation reloads namespaces from disk. The cost is ~500 ms × N calls for a session of N interactions.

The agent fights these every turn unless something holds the context.

A tmux session + a Clojure REPL inside it is that something. The tmux pane keeps shell state (CWD, env, history) across an unbounded number of agent-issued commands. The REPL inside it keeps language state — defined vars, loaded namespaces, in-memory data structures — across an unbounded number of agent-issued evaluations. Together they mask the subshell-statelessness problem that otherwise dominates agent-CLI-driven work.

The flight-tracking case below was executed under exactly that context. Eight hours of incremental work, all in one tmux session named flight-repl, hosting a bb repl process with the captured flt variable loaded at minute 12 and still accessible at minute 480. Every CLI tool we shipped (bin/watch-status, bin/closest-pass, bin/north-of, bin/overhead, bin/deviation) is a consolidation of forms that already worked in that REPL — not a freshly-authored script.

The flat alternative (a series of bb -e '(...)' one-shots) would have produced the same artifacts but at perhaps 10× the wall-clock cost: every probe reloads everything, every probe re-parses the snapshot, every probe is a fresh JVM/bb startup. The interactive context isn't faster because computers are faster; it's faster because the agent stops re-establishing context on every call.

Polar filed route: BIKF → RALOV → 64°N/30°W → 65°N/40°W → 65°N/50°W → AVPUT (65.03°N, 60°W) → 65°N/70°W → 64°N/80°W → 62°N/90°W → 59°N/100°W → 55°N/110°W → BINVO → YDC → JAKSN → GLASR3 → KSEA

Phase decomposition: taxi-out 14 min · airborne 7h 28m · taxi-in 7 min. The headline 4-minute improvement came entirely from airborne time; both taxi phases ran the assumed budget.

Filed polar route bends 200 km south of the pure great circle between endpoints. Quantified by ~geo.crosstrack/track-deviation over the 631 captured ADS-B/radar fixes — a single REPL form, against the same flt that's been loaded all day:

(r/deviation-from-route "ASA355" "2026-05-30" {:tier :adsb-only})
;; → {:n 562
;;    :max 360.8        ; km, at [65.053°N -59.308°W] (just past AVPUT
;;                      ;  over Davis Strait)
;;    :mean 158.9       ; km
;;    :argmax [65.053 -59.308]}

Switching :tier :all → :adsb-only filters out the radar tail (562 ADS-B vs 631 total). The max survives the filter — the canonical deviation extremum lands on an ADS-B fix. Useful tier-gating invariant for any claim asserted to better than ~50 km.

Initial single-heading inference said RWY 16 (south landing): final captured heading on approach was 176°–177° true. Wrong: the plane continued south past KSEA to lat 47.12°N, then reversed through 336° → 359° → 001° on the procedure turn and landed RWY 34 (north).

The fix came from track replay in the REPL — possible only because the captured fixes were already loaded:

(->> (w/positions "ASA355")
     (take-last 20)
     (mapv (fn [p] [(:timestamp p) (:heading p)])))
;; → 222° → 198° → 177°   ← downwind (looks like final)
;;   → 222° → 336° → 359° → 001°  ← 180° reversal = procedure turn
;;   → final, runway 34 northbound

Without the persistent REPL state, this debugging move would have needed a custom script reading the snapshot from disk, re-parsing JSON, then projecting fields. With it: one form, three seconds.

Generalizable rule for any landing-runway inference: never key on a single heading point; require the stable post-reversal segment.

Three "where is the plane relative to a fixed observer" queries, all answered from the captured tracklog. Observer here is KBOS (Boston Logan) as a stand-in for "any East Coast position":

The polar route never comes near the observer — the closest fact ("1,336 nm North") is geometrically right but operationally meaningless. The meridian-crossing fact is the right question to ask: "when does the plane cross your line of longitude?" That's bin/north-of in the toolset. The distinction between these two answers comes from naming the question precisely — the same discipline the project's geo.crosstrack spec applies to the four flavors of "deviation."

The chart above is the same projection toolchain run against the KBOS↔KSEA endpoint pair, overlaying the geodesic (green), the 4,000 km isochron from KBOS (orange dashed — Keflavík sits on the same shell as Seattle, ~131 km off), and the perpendicular bisector great circle (purple dashed) with M / M' anchors. The bisector threads through KTVF / BGQQ / MMTO / ULDD / KG-0001 / SCIP / VOMY — seven airports spanning every continent except Antarctica, all equidistant from Boston and Seattle in still air.

The captured endpoint pair (KBOS, KSEA) defines an equal-time locus — the perpendicular bisector great circle through midpoint M (47.87°N, -95.44°W) and antipode M' (47.87°S, 84.56°E). Closest scheduled airport to M is KTVF Thief River Falls at 60 km; most-balanced major hub is KICT Wichita (|d_BOS - d_SEA| = 3.5 km); most-balanced globally is Jalal-Abad, Kyrgyzstan at imbalance 0.7 km but 10,000 km out — a stretched-bisector point appearing at antipodal distance.

Refutation included in the toolset: equal-time = equal-distance only in still air. ASA355's own 360 km D3 deviation is the proof-of-concept that real flight time is wind-warped, not geometric.

Captured as a structured annotation in research/annotations.ndjson, linked to all three fa_flight_ids of the captured saga (Day 2 outbound

• Day 3 outbound + Day 3 inbound):

{ "fa_flight_id": "ASA355-1779955973-airline-1213p",
  "kind": "article",
  "title": "3,600 Miles: Alaska Airlines Launches Record-Longest
            Boeing 737 Flight By A US Carrier",
  "source": "simpleflying.com",
  "author": "Abid Habib",
  "published": "2026-05-31T16:00:00Z",
  "also_relates_to": [
    "ASA355-1779860627-airline-1198p",
    "ASA354-1779860627-airline-1197p" ],
  "facts_asserted": {
    "route_distance_mi": 3622,
    "service_launched": "2026-05-28",
    "previous_record_holder": "Alaska ANC→JFK",
    "world_longest_737": "GOL MCO→BSB at 3,778 mi"
  },
  "url": null,
  "url_status": "not provided in source paste" }

URL deliberately null per the project's URL-hygiene rule (no fabricated placeholders; cite by author/title/date until verified).

The annotated projection above is the artifact of a small Makefile chain that composes three live ingredients: the OurAirports EDN cache, the geo.crosstrack primitive ns, and a bb render script that calls those primitives to produce SVG. Each step is reproducible from a clean checkout; the static data (airports) ships in the repo so the chart rebuilds offline.

docs/case-studies/airport-projection-annotated.svg: \
    resources/airports.edn \
    bin/render-projection-annotated.bb \
    src/geo/crosstrack.clj
        bb bin/render-projection-annotated.bb $@

docs/case-studies/airport-projection-annotated.png: \
    docs/case-studies/airport-projection-annotated.svg
        rsvg-convert -w 2400 $< -o $@

airport-projection-annotated: docs/case-studies/airport-projection-annotated.png
.PHONY: airport-projection-annotated

The bb script (bin/render-projection-annotated.bb) is a thin composition of REPL forms — every overlay corresponds to one ct/* call, all evolved interactively before being persisted to the file:

(require '[geo.crosstrack :as ct]
         '[flight-tracking.repl.geo :as g])

(def BOS [42.3656 -71.0096])
(def SEA [47.4502 -122.3088])

;; the three geometric overlays:
(ct/gc-polyline BOS SEA 120)              ; geodesic (green)
(ct/isochron-circle BOS 4000.0 360)       ; 4,000 km from BOS (orange dashed)
(ct/perpendicular-bisector BOS SEA 240)   ; equal-time locus (purple dashed)

;; anchors:
(def M    (ct/gc-midpoint BOS SEA))       ; → [47.87°N -95.44°W]
(def M-A  (ct/antipode M))                ; → [-47.87°N  84.56°E]

;; airport DB for the base layer + bisector waypoint dots:
@g/airports-db    ; 6,198 entries; OurAirports, large + medium +
                  ; small-with-scheduled-service, keyed by ICAO

The base-layer airport plot uses a straightforward equirectangular projection (lon → x, lat → y), drawn in size order so large hubs sit on top of medium hubs sit on top of small. The polyline / circle / bisector overlays handle longitude wraparound at ±180° by splitting into segments. rsvg-convert -w 2400 renders the SVG to a 2400px PNG at the end.

What's interesting from the REPL discipline angle: every overlay function is a pure one-form computation against the same loaded state (BOS, SEA, M, the airports-db ref). The render script is a consolidation, not a translation — same code runs from the REPL when you're exploring ((spit "preview.svg" (page (overlay-svg ...))) and from the Makefile when you're shipping.

The full source for the bb script is in the project repo at bin/render-projection-annotated.bb; the bisector-equidistance invariant the chart depends on ((apply max (map abs (haversine-imbalances bisector-pts))) → 0.0) is one of the L1 properties the L0 geo.crosstrack ns asserts in its verify fn.

Three new REPL patterns surfaced here:

• Live-flight-data-as-REPL-state. flt defined at minute 12 and still accessible at minute 480 of the session. Every new function was probed against the same captured snapshot without restart or re-parse. The cost of loading the JSON snapshot is paid once.
• Track-replay-as-debugging. The runway-from-single-heading mistake was a snapshot-only error; one REPL form scanning the last 20 fixes surfaced the procedure-turn signature retroactively. The persistent REPL state made this an interactive examination, not a script-write.
• Property verification via single-form REPL probes. (geo.crosstrack/verify) → :ok covers 9 invariants + 3 golden fixtures including this flight's D3-max value. The same form is cheap from the REPL, cheap from CI later, written once.

The thesis the case demonstrates is in the first section: an agent working a real external system is much faster, and much harder to break, inside a tmux + REPL context than running short CLI commands in succession. The flight-tracking work is concrete enough — and free of secrets — to ship as the canonical demonstration of that model.

1. Not waiting for output — capture happens before eval completes
2. Assuming REPL state — sent Clojure to a shell prompt
3. Namespace not loaded — (r/help) fails without require
4. Working directory wrong — file operations fail silently
5. Quoting issues — shell interprets quotes before tmux sees them

# 1. Observe shape
./repl-eval '(keys (first data))'

# 2. Sample distribution
./repl-eval '(->> data (map :type) frequencies (sort-by val >))'

# 3. Bind result
./repl-eval '(def errors (->> data (filter #(= :error (:type %)))))'

# 4. Refine hypothesis
./repl-eval '(->> errors (group-by :source) (map (fn [[k v]] [k (count v)])))'

The REPL maintains state across evaluations — intermediate results persist for the entire session. This is the key advantage over scripts: each eval builds on previous work without re-computation.

The optimal setup: JVM nREPL runs as a daemon, Babashka scripts query it.

┌─────────────┐    Bencode/TCP    ┌─────────────────┐
│  Babashka   │ ←───────────────→ │   JVM nREPL     │
│  (10ms)     │    port 1667      │   (daemon)      │
│  Scripts    │                   │   Full Clojure  │
└─────────────┘                   │   AeroAPI libs  │
                                  │   Stateful      │
                                  └─────────────────┘

Why this architecture:

• JVM startup cost paid once (daemon)
• Babashka scripts start in 10ms
• Full Clojure available (specs, test.check, Java interop)
• State persists across queries (defs, loaded namespaces)
• LAN-accessible for remote agents

# Start daemon once
clj -M:dev -m nrepl.cmdline --bind 0.0.0.0 --port 1667 &

# Fast queries via Babashka (111ms vs 2.5s)
bb scripts/nrepl-query.bb '(count (all-ns))'
bb scripts/nrepl-query.bb '
  (require (quote [aeroapi.core :as api]))
  (def client (api/from-env))
  (count (:arrivals (api/request client {:method :get :path "/airports/KBOS/flights/arrivals"})))
'

Babashka speaks raw Bencode to the JVM daemon:

#!/usr/bin/env bb
;; nrepl-query.bb - Fast queries to JVM nREPL daemon

(defn bencode [data]
  (cond
    (integer? data) (str "i" data "e")
    (string? data) (str (count (.getBytes data "UTF-8")) ":" data)
    (map? data) (str "d" (apply str (mapcat (fn [[k v]] [(bencode k) (bencode v)])
                                             (sort-by key data))) "e")))

(defn nrepl-eval [code]
  (let [sock (java.net.Socket. "localhost" 1667)
        out (.getOutputStream sock)]
    ;; Clone + eval + collect responses
    (.write out (.getBytes (bencode {"op" "clone"})))
    ;; ... parse bencode responses ...
    ))

(when (seq *command-line-args*)
  (println (:value (nrepl-eval (first *command-line-args*)))))

Benchmark: 100 iterations of (+ 1 2) against running JVM nREPL daemon.

=== Benchmark Results (hydra, FreeBSD 14.3) ===

Simple query '(+ 1 2)' - 100 iterations:
  Min: 103ms  Max: 184ms  Avg: 115ms

API query with AeroAPI call - 10 iterations:
  Avg: 1081ms (includes ~500ms network latency)

JVM client - 3 iterations:
  Avg: 2462ms

Key insight: The Babashka client overhead is ~115ms. The JVM client pays ~2400ms of startup cost every invocation. For agent automation where you may issue hundreds of queries, this 21x speedup adds up.

The daemon architecture gives agents full JVM Clojure power with Babashka-level startup times. Best of both worlds.

1. Daemon lifecycle — Start nREPL on boot or first use. It holds state (loaded namespaces, defs) across queries. Restart to reset.
2. Connection pooling — Each nrepl-query.bb call opens a new connection. For burst queries, consider keeping a session open.
3. Error handling — Bencode parse errors are silent. Add logging in production scripts.
4. LAN security — Binding to 0.0.0.0 exposes nREPL. Use firewall rules or bind to specific interface (Tailscale IP recommended).
5. Memory — JVM daemon holds loaded code in memory. For long-running daemons, monitor heap usage.

For JVM-to-JVM communication (editor integration):

(require '[nrepl.core :as nrepl])
(with-open [conn (nrepl/connect :host "hydra" :port 1667)]
  (let [client (nrepl/client conn 5000)
        session (:new-session (first (nrepl/message client {:op "clone"})))]
    (doseq [msg (nrepl/message client {:op "eval" :code "(+ 1 2)" :session session})]
      (when (:value msg) (println (:value msg))))))

Full skill with references: gist:nrepl-bencode-experience